github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-07-15 14:43:36 -05:00
Code Issues 3.0k Packages Projects Releases 58 Wiki Activity

[GH-ISSUE #7358] [Bug]: Scheduled Transaction won't save if dollar sign in Schedule Name #100476

New Issue
Open
opened 2026-05-29 20:08:41 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-05-29 20:08:41 -05:00
Owner
Copy Link

Originally created by @oysterville on GitHub (Apr 2, 2026).
Original GitHub issue: https://github.com/actualbudget/actual/issues/7358

What happened?

I was trying to create a scheduled transaction today with a dollar sign in the name, and the red "Something went wrong" error message came up. I've cleared cache and repaired database with same result. Posting same scheduled transaction without dollar sign works.

This occurs if schedule is repeating or not.

How can we reproduce the issue?

  1. Go to Schedule
  2. Put dollar sign in Schedule Name (additional characters irrelevant)
  3. Enter transaction settings
  4. Click Save

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Firefox

Operating System

Linux

Originally created by @oysterville on GitHub (Apr 2, 2026). Original GitHub issue: https://github.com/actualbudget/actual/issues/7358 ### What happened? I was trying to create a scheduled transaction today with a dollar sign in the name, and the red "Something went wrong" error message came up. I've cleared cache and repaired database with same result. Posting same scheduled transaction without dollar sign works. This occurs if schedule is repeating or not. ### How can we reproduce the issue? 1. Go to Schedule 2. Put dollar sign in Schedule Name (additional characters irrelevant) 3. Enter transaction settings 4. Click Save ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Firefox ### Operating System Linux
GiteaMirror added the schedulesbuguser interface labels 2026-05-29 20:08:43 -05:00
GiteaMirror commented 2026-05-29 20:08:50 -05:00
Author
Owner
Copy Link

@alecbakholdin commented on GitHub (Apr 26, 2026):

TL;DR: you can still use $, you just can't start your schedule name with it.

Some more details in case someone wants to tackle this in the future: The full error message is Invalid field reference: $\n\nExpression stack:\n $\n {"name":{"$eq":"$"}}\n filter({"name":"$"}). This comes from the aql/compiler.ts file. When creating a schedule we create a filter name = '<schedule_name>' where we substitute the user input. There are two cases where this behaves weirdly.

  1. If it starts with a '$', the compiler attempts to treat it as an implicit field.
  2. If it starts with a ':', the compiler attempts to treat it as a named parameter.
    if (expr[0] === '$') {
      const fieldRef = expr === '$' ? state.implicitField : expr.slice(1);

      if (fieldRef == null || fieldRef === '') {
        console.error('we are erroring right now')
        throw new CompileError('Invalid field reference: ' + expr);
      }

      return transformField(state, fieldRef);
    }

    // Named parameter
    if (expr[0] === ':') {
      const param = { value: '?', type: 'param', paramName: expr.slice(1) };
      state.namedParameters.push(param);
      return param;
    }
  }

I don't know much about the nitty gritty AQL stuff so don't really have much insight beyond this (first time hearing about implicit fields or named parameters), but the fully qualified steps to recreate involves starting your schedule name with '$' or ':', so $test doesn't work but test$ does.

<!-- gh-comment-id:4323316089 --> @alecbakholdin commented on GitHub (Apr 26, 2026): TL;DR: you can still use $, you just can't *start* your schedule name with it. Some more details in case someone wants to tackle this in the future: The full error message is `Invalid field reference: $\n\nExpression stack:\n $\n {"name":{"$eq":"$"}}\n filter({"name":"$"})`. This comes from the aql/compiler.ts file. When creating a schedule we create a filter `name = '<schedule_name>'` where we substitute the user input. There are two cases where this behaves weirdly. 1. If it starts with a '$', the compiler attempts to treat it as an implicit field. 2. If it starts with a ':', the compiler attempts to treat it as a named parameter. ``` if (expr[0] === '$') { const fieldRef = expr === '$' ? state.implicitField : expr.slice(1); if (fieldRef == null || fieldRef === '') { console.error('we are erroring right now') throw new CompileError('Invalid field reference: ' + expr); } return transformField(state, fieldRef); } // Named parameter if (expr[0] === ':') { const param = { value: '?', type: 'param', paramName: expr.slice(1) }; state.namedParameters.push(param); return param; } } ``` I don't know much about the nitty gritty AQL stuff so don't really have much insight beyond this (first time hearing about implicit fields or named parameters), but the fully qualified steps to recreate involves *starting* your schedule name with '$' or ':', so `$test` doesn't work but `test$` does.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
tech-support
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label bug schedules user interface
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#100476
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?