Conversation
…commands When called via HTTP with awaitResponse=false, the refresh joined the async thread's batched transaction (commitEvery=10240) and changes were never committed promptly. Using joinCurrentTx=false ensures the refresh always creates its own dedicated transaction that commits to disk immediately, regardless of whether an outer transaction is active. Fixes #3941 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Coverage variation | ✅ -8.87% coverage variation |
| Diff coverage | ✅ 100.00% diff coverage |
Coverage variation details
Coverable lines Covered lines Coverage Common ancestor commit (b24f775) 117458 87273 74.30% Head commit (d20a464) 148697 (+31239) 97295 (+10022) 65.43% (-8.87%) Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch:
<coverage of head commit> - <coverage of common ancestor commit>
Diff coverage details
Coverable lines Covered lines Diff coverage Pull request (#3942) 1 1 100.00% Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified:
<covered lines added or modified>/<coverable lines added or modified> * 100%
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes. Give us feedback
There was a problem hiding this comment.
Code Review
This pull request addresses issue #3941 by ensuring that materialized view refreshes always use a dedicated transaction, preventing them from being deferred in asynchronous contexts. This was achieved by setting the joinCurrentTx parameter to false in the MaterializedViewRefresher class. A comprehensive integration test has also been added to verify the fix for both synchronous and asynchronous HTTP commands. I have no feedback to provide.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3942 +/- ##
==========================================
- Coverage 65.37% 64.75% -0.62%
==========================================
Files 1582 1582
Lines 117458 117458
Branches 24959 24959
==========================================
- Hits 76790 76065 -725
- Misses 30215 30994 +779
+ Partials 10453 10399 -54 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…o [skip ci] Bumps [marked](https://github.com/markedjs/marked) from 18.0.0 to 18.0.2. Release notes *Sourced from [marked's releases](https://github.com/markedjs/marked/releases).* > v18.0.2 > ------- > > [18.0.2](markedjs/marked@v18.0.1...v18.0.2) (2026-04-18) > ----------------------------------------------------------------------------------- > > ### Bug Fixes > > * fix infinite loop for indented code blank line ([ArcadeData#3947](https://redirect.github.com/markedjs/marked/issues/3947)) ([58a52e8](markedjs/marked@58a52e8)) > > v18.0.1 > ------- > > [18.0.1](markedjs/marked@v18.0.0...v18.0.1) (2026-04-17) > ----------------------------------------------------------------------------------- > > ### Bug Fixes > > * **rules:** ensure lookbehind regex is evaluated correctly by minifiers ([ArcadeData#3945](https://redirect.github.com/markedjs/marked/issues/3945)) ([abd907a](markedjs/marked@abd907a)) Commits * [`c4f4529`](markedjs/marked@c4f4529) chore(release): 18.0.2 [skip ci] * [`58a52e8`](markedjs/marked@58a52e8) fix: fix infinite loop for indented code blank line ([ArcadeData#3947](https://redirect.github.com/markedjs/marked/issues/3947)) * [`98b3824`](markedjs/marked@98b3824) chore(release): 18.0.1 [skip ci] * [`abd907a`](markedjs/marked@abd907a) fix(rules): ensure lookbehind regex is evaluated correctly by minifiers ([ArcadeData#3945](https://redirect.github.com/markedjs/marked/issues/3945)) * [`96351c4`](markedjs/marked@96351c4) chore(deps-dev): bump marked-highlight from 2.2.3 to 2.2.4 ([ArcadeData#3946](https://redirect.github.com/markedjs/marked/issues/3946)) * [`c132699`](markedjs/marked@c132699) chore: update testutils ([ArcadeData#3942](https://redirect.github.com/markedjs/marked/issues/3942)) * See full diff in [compare view](markedjs/marked@v18.0.0...v18.0.2) [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
Summary
Fixes #3941
REFRESH MATERIALIZED VIEWsent via HTTP withawaitResponse: falsehad no visible effect on the view data.Root cause:
MaterializedViewRefresher.fullRefresh()calleddatabase.transaction(lambda)with the defaultjoinCurrentTx=true. In async mode the async thread already holds a long-running batched transaction (commitEvery=10240by default). The refresh joined that transaction and its changes were never committed promptly — effectively the view was not updated from the caller's perspective.Fix: Changed to
database.transaction(lambda, false). WithjoinCurrentTx=falsethe refresh always creates a dedicated transaction (nested on the outer one if present) that is committed to disk immediately on success. This works correctly in all call contexts:Test plan
Issue3941AsyncRefreshMaterializedViewITcovering both async (awaitResponse=false) and sync pathsIssue2097AsyncRebuildIndexIT(related async scenario) still passes🤖 Generated with Claude Code