Subtransactions not included in /id/transactions when deleted?

Hey there!

I'm about to finish my first project with YNAB which manages shared categories between budgets, and I'm in the process of bugtesting it and came across what I believe is a bug with deleted subtransactions. - They just won't appear in the /budget_id/transactions file.

 

Example where the entire split is deleted:

    "transactions":[
         {
            "import_id":null,
            "category_id":"category-id",
            "account_id":"account-id",
            "flag_color":null,
            "payee_id":"payee-id",
            "memo":"",
            "account_name":"TestVisa",
            "subtransactions":[

            ],
            "approved":true,
            "transfer_account_id":null,
            "amount":-400000,
            "transfer_transaction_id":null,
            "matched_transaction_id":null,
            "deleted":true,
            "date":"2019-01-14",
            "cleared":"uncleared",
            "payee_name":"123",
            "id":"id",
            "category_name":"Split (Multiple Categories)..."
         },

 

And where 1 of 3 splits are deleted (doesn't appear):

{
            "import_id":null,
            "category_id":"category-id",
            "account_id":"account-id",
            "flag_color":null,
            "payee_id":"payee-id",
            "memo":"",
            "account_name":"TestVisa",
            "subtransactions":[
               {
                  "transfer_account_id":null,
                  "memo":"",
                  "payee_id":null,
                  "deleted":false,
                  "amount":-200000,
                  "transfer_transaction_id":null,
                  "category_id":"category_id",
                  "id":"id",
                  "transaction_id":"transaction_id"
               },
               {
                  "transfer_account_id":null,
                  "memo":"",
                  "payee_id":null,
                  "deleted":false,
                  "amount":-100000,
                  "transfer_transaction_id":null,
                  "category_id":"category_id",
                  "id":"id",
                  "transaction_id":"transaction_id"
               }
            ],
            "approved":true,
            "transfer_account_id":null,
            "amount":-300000,
            "transfer_transaction_id":null,
            "matched_transaction_id":null,
            "deleted":false,
            "date":"2019-01-14",
            "cleared":"uncleared",
            "payee_name":"Test",
            "id":"ID",
            "category_name":"Split (Multiple Categories)..."
         },

 

Is this an oversight/something we can see added? :)

8replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • I have a couple of questions, Sondre G . Are you passing in `last_knowledge_of_server`? I suspect you might be since you show a transaction with the property/value `deleted":true` in one of your examples. You should only get those back with delta requests. So...

    • If you want to use delta requests, pass in `last_knowledge_of_server`.
    • If you want to get back tombstoned transactions/subtransactions, you must use delta requests
    • If you pass `last_knowledge_of_server = 0` you're making a delta request, and you'll get back every entity. (It's an undocumented hack).

    If you are making delta request and are not seeing "deleted" records, it's likely a bug on our end and we can certainly fix it. Let me know. Thanks!

    Reply Like
  • George I'm passing Delta requests and merging with a local cache; but not in /budget_id/transactions rather in /budget_id/. Sorry should've specified this!

    Reply Like
      • Sondre G
      • Media Producer
      • Silver_Mask.2
      • 7 mths ago
      • Reported - view

      Sorry for double post: Is it intentionally not part of the main /budget_id/ parameter? I wanted to avoid using too many requests and caching the entire budget seemed like the ideal solution.

      Sondre

      Reply Like
  • Hey, Sondre G . You're doing it correctly. GET /budgets/{budget_id} supports delta requests and should behave as described for /transactions, above. It sounds like it's an issue on our end. Give me a couple of days to look into it. I'll post here when I have more.

    Thanks for your patience. 🙂

    Reply Like
  • That's great news! :) - On the subject of caching & changing /budgets/id/: I'm not sure if it's common practice but is it possible to have a 'json-version' next to 'server-knowledge' in order to know when a JSON structure has been modified? So if applicable we could automatically flush the cache and get the newest version? George

    Reply Like
      • George
      • Developer
      • george_ynab
      • 6 mths ago
      • Reported - view

      Sondre G , what do you mean by "when a JSON structure has been modified"?

       

      We build the JSON on the fly so there's no real way on our end to compare the current JSON representation with a previous one. 

      Reply Like
      • Sondre G
      • Media Producer
      • Silver_Mask.2
      • 6 mths ago
      • Reported - view

      George I was just assuming that if the subtransactions were added, I wouldn't automatically get them unless I requested data without passing server knowledge. I might be wrong on this.

       

      So if there were like a JSON version reference for every category I could compare them to what the JSON version is in my cache, and if there's a difference it will remake the cache. 

      Like: 

      transactions:[
        "version":100
        {
          "transactiondata":here
        },
        {
          "transactiondata2":here
        }
      ]

       

      But as I mentioned it's probably not necessary

      Reply Like
      • George
      • Developer
      • george_ynab
      • 6 mths ago
      • Reported - view

      Sondre G If subtransactions are added, they should have a higher server_knowledge than your last_knowledge_of_server, and so would be returned for a delta request. Does that answer your question? (And apologies for the delay getting back to you, I've been a bit under the weather.)

      Reply Like
Like Follow
  • 6 mths agoLast active
  • 8Replies
  • 110Views
  • 1 Following