Tree-cached query capture nodes are not updated during tree edits.

[Calliope]

I have a query that is behaving strangely;
as I make four replacements in my code,
the query capture nodes are updated (based on a tree cache) for some changes I make,
but fail to update after the third change.

As I log my query's captured nodes in the console after each change,
you can see an edit to the name of the JSX element Lens.change -> ChargeCard
updates the captured nodes;
the following change to delete the source captured attribute
leaves the captured nodes pointing to stale indexes in the code,
making my subsequent change, deleting the code captured attribute, impossible.

Boiled down:

[ 'source', 570, 609, 'source="app/javascript/packs/charge.js"' ],
[ 'code', 610, 621, 'code="abcd"' ],

// -> change JSX opening tag name using a tree edit

[ 'source', 569, 608, 'source="app/javascript/packs/charge.js"' ],
[ 'code', 609, 620, 'code="abcd"' ],

// -> delete "source" attribute using a tree edit

[ 'source', 569, 608, ' code="abcd"\n        onClick={(e) => {\n' ],
[ 'code', 609, 620, '         e.' ],

code under analysis:

      <Lens.change source="app/javascript/packs/charge.js" code="abcd"
        onClick={(e) => {
          e.preventDefault()
          chargeCard()
        }}
      >
        Charge your card.
      </Lens.change>

code producing changes:
https://github.com/assembleapp/donors/blob/tree-sitter/hierarch/parse.js#L51-L121
https://github.com/assembleapp/donors/blob/tree-sitter/hierarch/program.js

Can you recommend any approaches? Much obliged.

[Calliope]

Ah!

I changed around my edits, and realized that the nodes are only becoming un-synced after the second edit, no matter where the edits take place. I'm sure this is caused by this.parsed = this.parser.parse(changed_source, this.parse), where this.parsed is my tree;
https://github.com/assembleapp/donors/blob/tree-sitter/hierarch/program.js#L28
the first change updates the query capture nodes, because they are part of the original tree.
The tree is replaced before the second edits take place, so when we change the second tree our capture nodes (cached by the original tree) are unaffected.

I can look into batching the changes I need to make, so they all take place on one tree, before re-parsing occurs.

Closing because the underlying issue is not with the tree-sitter APIs.