Skip to content

Conversation

@pull
Copy link

@pull pull bot commented Jan 20, 2026

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

n-crrn and others added 3 commits January 20, 2026 16:49
CC: @brookjeynes-ssw @kulesy 

This change fixes an issue where a leg of a query may continue execution
after another leg has already failed and the resolver has returned the
error message. The significance is that the continuing query can then
fail during a separate later query, causing a spurious error that has
nothing to do with the later query.

The fix works by tracking all field resolver promises that are created,
and then ensuring that they are all settled before exiting the `resolve`
function. The GitHub formatting of the change obscures the form of the
fix within the `resolve` function of `resolve.ts`, but it can be
summarised as follows:

```ts
// Track all field resolver promises to prevent runaway promises.
const resolverPromises: Promise<unknown>[] = [];
...
resolver: async (...) => {
    const fieldPromise = (async () => { /* Old resolver */ })();
    resolverPromises.push(fieldPromise);
    return fieldPromise;
}
...
// Ensure all field resolvers have completed before continuing, as errors can cause
// a premature return.
await Promise.allSettled(resolverPromises);
```

Regarding alternative approaches:

- An
[AbortController](https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal#examples)
could be used as a cancellation token with the `Database.query` method
to cease a query early. However, this would require more complicated API
and logic changes.
- No attempt is made to remove completed promises from the
`resolverPromises` array, as it would complicate the logic and risk race
conditions when modifying the array.

In addition to the fix, a test is included that demonstrates the bug.

- The test works by delaying the return of calls to `Database.query`.
When the bug is present, the test assertions are evaluated before the
query completes.
- I have not been able to devise a reliable and easily understood way to
coordinate the sequence without timeouts. To help ensure the integrity
of the test during a run, a timeline of events is maintained within the
test.
- The test does not use the existing test `setup*` functions in
`tests/util.ts`, as the methods of the `Database` object need to be
overridden rather than those of the `Bridge`.

---------

Co-authored-by: Jack Pettit [SSW] <57518417+JackDevAU@users.noreply.github.com>
Co-authored-by: kulesy <kulewidak@gmail.com>
Co-authored-by: Eli Kent [SSW] <69125238+kulesy@users.noreply.github.com>
## Summary
- Adds a condition to prevent the publish workflow from running on
forked PRs
- This ensures that the `tagged` label publish only triggers for PRs
from the main repository, not from forks
- This is because our NPM OIDC policy does not allow publishes from
forked repositories
…thod provided (#6362)

### Description

This PR fixes the filename input for Tina so that if the developer marks
the field as **read only** the user will not be able to edit it the
filename. I achieved this by changing the fallback logic for the
FileName component to use the default text field when the field is
marked as read only. The default text input already disables the status
of fields marked as **readonly**, fixing the issue.

### Fixed
- #6361 

### Done Video


https://github.com/user-attachments/assets/5c577a46-fbb7-4b14-a325-ad305bfeaf52

---------

Co-authored-by: Eli Kent [SSW] <69125238+kulesy@users.noreply.github.com>
@pull pull bot locked and limited conversation to collaborators Jan 20, 2026
@pull pull bot added the ⤵️ pull label Jan 20, 2026
@pull pull bot merged commit 6647240 into code:main Jan 20, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants