Repository navigation
fix(reply-sla): bound conflict recovery and repair rollback-expired inputs #1669
Description
Current authority — 2026-09-19
The 2026-09-11 Jules N+1 DB Flush Issue in Reply SLA Escalation Service was valid, but the canonical source owner is now #1486, not direct-develop predecessor #1670.
- protected
develop:042b0c70531b229af3acbd0421a2f23098d848b3 - canonical combined owner: feat(noema-agent): add calendar conflict-check tool #148622c173b
- source-repair predecessor: fix(reply-sla): bound conflict retries and restore rollback-safe inputs #1670 exact
e17bbc27040ddeb4e1de6e12815f5aa74a5c9672, frozen Draft provenance - workspace/Alembic owner: fix: create workspace_entities/workspace_documents registry and provision Workspace rows #1503 exact
9151c75568c582c8147cfee6757cd00a9b4d60b7 - dependency-security owner: fix(deps): patch frontend audit security floors #1623 exact
509be4c1d9b6c7ba239a108656e2382681a85341 - canonical Gap writer: docs(gap): integrate visual and owner-handoff evidence #1602 only
Verified defect and source succession
The ordinary Reply-SLA escalation path batches task creation and commits once. The real linear-round-trip defect was the repeated-conflict fallback: after uniqueness races it could degrade into per-task SAVEPOINT/flush retries. The old path also double-expunged inserts already detached by SAVEPOINT rollback and could reuse rollback-expired Email rows without one explicit owner-scoped reload.
No external LLM/network call or explicit row-lock statement was found in the inspected escalation path. The finding is transaction/round-trip correctness under contention; no production deadlock or p95 claim is inferred.
Every changed #1670 path is represented in #1486: CHANGELOG.md, backend/api/tasks.py, backend/services/reply_sla_escalation_service.py, backend/tests/test_reply_sla_transaction_budget.py, backend/tests/test_tasks_api.py, and docs/doctoring/reply_sla_batch_conflicts.md.
The combined owner keeps #1486's workspace and scheduler semantics while carrying the causal repair:
- at most
REPLY_SLA_MAX_BATCH_ATTEMPTS = 3batch SAVEPOINT/flush attempts; - no per-task SAVEPOINT fallback;
- one batched winner read per failed uniqueness batch;
- complete rollback on exhausted contention with
reply_sla_batch_retry_exhausted; - driver-code-based classification for known non-unique integrity failures without localized error-text parsing;
- primitive Email IDs retained before rollback;
- rollback-expired sources reloaded in one
user_id + organization_id + workspace_idquery, with source deletion/owner/org/workspace movement failing closed; - stable machine-readable
ReplySlaTaskConflict.error_codepreserved at the HTTP 409 boundary; - completed tasks remain closed and existing task identity/result authority is preserved.
backend/tests/test_reply_sla_batch_conflict_owner_integration.py locks the bounded-attempt and workspace-aware owner integration contract. #1670 remains predecessor provenance and must not merge independently.
Live prerequisite topology
#1623's exact 509be4c1... generation has Application CI, Bandit, Semgrep, Docker, Security and CodeQL terminal SUCCESS plus exact-head approval, but a later #1718 Trivy run observed newer protected-base next/sharp vulnerabilities. After the central workflow/base contract settles, #1623 must reacquire the Security evidence actually invalidated by the changed ancestry/current vulnerability database rather than treating its older GREEN as proof of the later scan generation.
Central authority is now more specific than the earlier #2040@ee6781d... note. Protected .github/main remains 64aa08d7fa487deacd41c761c36277ca68cab6c9; scheduler/producer owner #2040 remains exact 12c3fa6f3623aa5f2979d3d5ee4ed987002a6c0d, Draft/open/non-mergeable. Because #2040 and protected main both changed the shared scheduler after merge base fb17ef556f94f673234aa557254ae52779e9a7b0, the next scheduler action is ordinary/non-force path-wise protected-main reconciliation first, preserving valid owner deltas and compatible current-main queue/capacity behavior while resolving the production repository-identity RED.
The central base-SAST/security lane is also independently incomplete. .github#2269@a83d6d325c28620bb393d7b79a3cc74fe8130c38 and .github#2272@5b9e8642361818769d58af6f4e17a6087c90f6ad both harden initial https://api.github.com URL admission, but Python urllib.request redirects remain a demonstrated credential-egress RED: a 30x redirect to another origin can carry the Authorization header unless redirects are rejected or every target is revalidated. #2272 additionally owns the deploy-pages.yml caller-input shell-injection repair, but central Semgrep excludes .github/workflows, so that repair still needs an executable workflow-security regression. #2269 also carries focused CodeQL-helper regression delta not yet fully inherited by #2272. Both remain Draft; their hosted runs are not acceptance evidence.
Related central repository-identity repair slices #2268 and #2271 remain source authority only while their hosted evidence is unsettled. The external authenticated repository_dispatch canary remains a separate prerequisite; #1623's repository-local CodeQL GREEN does not replace it.
Close boundary
Keep this issue open. Source succession is present, but acceptance still requires:
- central #2269/#2272 valid production+test delta convergence (or a verified complete successor), including redirect credential containment and deploy-workflow regression;
- #2040 path-wise protected-main reconciliation, adopting/adapting repaired #2268/#2271 slices where applicable, followed by focused scheduler/repository-identity GREEN, fresh exact-head hosted checks and qualifying independent review;
- unchanged external dispatch canary success and terminal receiver settlement;
- fix(deps): patch frontend audit security floors #1623 revalidation under the then-current workflow contract and vulnerability database, then protected integration;
- fix(db): make fresh Alembic bootstrap tolerate retired emails schema #1694 and fix(ci): make stacked PR validation a develop prerequisite #1691 prerequisite integration in order;
- fix: create workspace_entities/workspace_documents registry and provision Workspace rows #1503 protected integration and one-head Alembic reconciliation;
- ordinary/non-force feat(noema-agent): add calendar conflict-check tool #1486 ancestry reconciliation;
- real async PostgreSQL uniqueness-race, exhausted-contention/no-partial-write, source scope-change, scheduler-lease, migration, security and warning-clean evidence on the final exact combined head;
- zero actionable current-head review findings/threads and qualifying independent approval.
Do not merge #1670 independently, re-copy its service over #1486, create a second Reply-SLA writer, weaken scanners, manufacture a no-op run, or hold a long transaction across external/model work.
Activity
fix(reply-sla): preserve HTTP conflict contract without hiding typed …
seonghobae commentedon Sep 12, 2026
Implemented repair and current acceptance state
The finding is now repaired in Draft #1670, current head
b2ee9c792938ae9dfe2d3e8310cffd628469168f, against unchanged protected develop042b0c70531b229af3acbd0421a2f23098d848b3. Exactly three files changed: escalation service, focused transaction regressions, investigation. The existing #1486/#1648 heads remain unchanged; integration guidance preserving #1486's workspace/physical-connection boundaries was posted there.The original ordinary path was already batched. The verified linear flush defect was the repeated-conflict per-row SAVEPOINT fallback. The repair uses up to three batch attempts, complete rollback / existing HTTP 409 on unresolved contention, a single owner-scoped reload after outer rollback, and no double-expunge. It preserves existing task UID, completed state, ordering and authoritative mutation responses. Driver-typed FK/NOT NULL/CHECK errors and pre-savepoint flush errors are preserved after cleanup; untyped IntegrityError retains the pre-existing API conflict contract, without claiming the cause is proven unique.
Current verification
68cba1d6f858ea4de732ed0761d57484513f8626(current head into unchanged develop); Python 3.14.7 / SQLAlchemy 2.0.51; Ruff passed; 1830 passed, 32 skipped in 14.66s. Skips are not counted as passes. The existing HTTP409 machine-readable-detail test was unchanged and now passes after repairing the first candidate's regression.Remaining integration gates, not waived
Current exact-head Security Scan 34683554003, Trivy job 103526478517, failed on the same three inherited
frontend/pnpm-lock.yamlfindings after refreshing the vulnerability database: next CVE-2026-75604 (CRITICAL 9.1), next GHSA-2xp9-vwfh-vxw4 (CRITICAL 9.5), sharp GHSA-rgj7-g3m4-5g8c (HIGH 8.0). This repair does not change dependency files. Canonical frontend security owner #1623 already received the earlier exact-head evidence in comment 5644769237; this current receipt confirms the finding persists in this descendant. Inherited does not mean safe; no ignore or exception was added.CodeQL PR 34683553958 currently fails closed because the authenticated current-head central verdict is absent, not because a source finding was established. Python compatibility job 103526488904 logged
DISPATCH_OUTCOME=success,VERDICT_STATE=pending; dispatch job 103526904751 subsequently completed successfully. Current commit statuses show Devin Review and CodeRabbit success, but no terminal codeql-dispatch verdict. Awaiting such a verdict is not a GREEN scan; no manual requeue, empty push, self-approval, or gate weakening was used.Scanner/runner output limitations are retained rather than hidden: Trivy skipped Python license detection because site-packages was absent; its binary reported a newer release available; SARIF base-SHA calculation fell back to the server after the shallow checkout lacked the synthetic merge object, while upload itself succeeded. StepSecurity's post-job agent.service syslog deprecation was also recorded on #1670. These are not claims that the Python test warnings gate failed, nor that the overall warning inventory is clean.
Keep this issue OPEN until the dependency-owner repair and required scanner verdicts, real asynchronous PostgreSQL race/rollback qualification, qualifying independent current-head approval and protected integration are satisfied. Code and regression repair are published; no default-branch merge, deployment or release has occurred. Source review and scoped SQLite/hosted application tests do not establish production deadlock incidence, p95 speedup, exactly-once execution, or all-gates-green.
seonghobae commentedon Sep 18, 2026
2026-09-19 prerequisite refinement
Central CodeQL acceptance gained a new stacked owner that must be included before this Reply-SLA issue can close.
.github#2275@443c9f6013a831b7e4605532809f7aae375d1019is stacked directly on#2271@2b849c874122961e025c29f7fa0bb697863c3d68and owns target GHAS/code-scanning analysis-read credential selection. It capability-probes the targetcode-scanning/analysesendpoint instead of selecting a non-empty token by presence. This is a central owner contract only; #1486/#1670 do not copy it.#2275 is still RED/incomplete: current CodeRabbit thread
PRRT_kwDOS_C14s6j3erFis unresolved because the fail-closed test assertsresult.stderrwhile the selector writes the::error::no configured credential can read target CodeQL analyses...diagnostic to stdout; exact Security35384698705, CodeQL35384698801, and Semgrep35384698974runs remain queued. Review metadata also reports 75% diff-scoped docstring coverage, below the 100% owned-production documentation target..github#2272@5b9e8642361818769d58af6f4e17a6087c90f6adhas likewise moved: Semgrep35346250233is now SUCCESS, but Agent Review Runtime Quality35346250239is terminal FAILURE atVerify exact-head path policy and syntax; CodeQL/Python Security/Security remain queued. The failure rejects legitimate.config/semgrep.ymland.github/workflows/deploy-pages.ymlsecurity paths before later tests. Repair must be narrow; the redirect credential-egress RED, deploy-pages executable regression, and #2269 focused CodeQL-helper regression inheritance are still unresolved.Closure order is refined to #2269/#2272 valid security-delta convergence + #2275 correction/acceptance → #2040 path-wise protected-main reconciliation with the latest valid #2268/#2271/#2275 slices where applicable → fresh central exact-head acceptance + qualifying review → external dispatch canary → #1623 current-vulnerability revalidation → #1694 → #1691 → #1503 → #1486 final PostgreSQL contention/workspace/lease/security/review evidence. Keep this issue open; no additional Reply-SLA source change is justified by these central findings.
seonghobae commentedon Sep 18, 2026
Correction to the preceding prerequisite note
.github#2275advanced ordinary-forward to exacta900ec17f1e4a7db384e3052c23d3cf7440f0651after the previous comment. Its only new delta is +1/-1 in the focused GHAS credential regression, changing the fail-closed assertion fromresult.stderrtoresult.stdout. CodeRabbit threadPRRT_kwDOS_C14s6j3erFis now resolved/outdated, so that specific finding is repaired.Acceptance is still pending: fresh exact-head Security
35389309836, CodeQL35389309810, and Semgrep35389309876are queued, the PR remains Draft, and no qualifying current-head approval exists. The earlier diff-scoped docstring report was 75%, so the 100% owned-production documentation target is still unproven. Keep the closure order from the preceding note but replace stale #2275443c9f6...state with currenta900ec17...; no new Reply-SLA source change follows from this central test repair.seonghobae commentedon Sep 18, 2026
#2275 exact-head advance
Central #2275 is now exact
a3b8cc1017acb82ed9a002c1f591c70617ad87e6. The advance froma900ec17...is doctoring-only (+11/-5), preserves the corrected fail-closed stdout assertion, and records all three OriginWeave language shards as terminal at the same immediate GHAS identity failure. Fresh Security35389422805, Semgrep35389422859, and CodeQL35389422758are queued. Replace the stale exact-head reference in the preceding note; Reply-SLA closure order is otherwise unchanged.seonghobae commentedon Sep 19, 2026
2026-09-19 central prerequisite correction
Fresh owner read supersedes the older #2269/#2272/#2275 snapshots in this issue thread.
.github#2279is now the canonical protected-base GitHub-API authority lane at exact25f83aaee9eb97e423f6ef2467e722035bc2e362. It rejects redirects for both authenticated urllib clients and its latest ordinary-forward repair moves all CodeQL GHAS transport fixtures onto the actual_GITHUB_API_OPENER.openseam. Its Python Security35423129349, CodeQL35423129337, Agent Review Runtime Quality35423129378, Semgrep35423129332, and Security35423129448runs are still queued, so this is repaired source, not GREEN acceptance..github#2272is exact4967d66f303bde675080466e359e75c260a91e06and separately owns the reusable Pages caller-input shell boundary plus an executableDeploy Pages Input Security CI. Its six exact-head runs are also queued. It is not a complete redirect-authority successor until the #2279/#2269 security contract is inherited losslessly..github#2275is exactfc9c5537d9910f0536dab2aaf52888078c8ead64. It owns GHAScode-scanning/analysescredential capability selection only and now records #2279 as its foundation prerequisite. Capability selection does not create target-repository permission..github#2276remains a separate open permission/canary issue after a reproduced targetcode-scanning/analysesHTTP 403 (Resource not accessible by integration). Acceptance still requires an unchanged target canary that reads protected-base and exact-head analyses and completes language pairing..github#2040remains exact12c3fa6f3623aa5f2979d3d5ee4ed987002a6c0d, Draft/open/non-mergeable. The scheduler production repository-identity RED is still present, so its next branch-moving action remains ordinary/non-force path-wise protected-main reconciliation rather than a stale one-line patch or whole-file adoption.The Reply-SLA source succession in #1486 does not change. The current closure path is therefore: central authenticated-HTTP/Pages deltas converge without loss → #2275 capability selector + #2276 real analyses-read permission/canary → #2040 protected-main reconciliation and fresh central exact-head acceptance/review → #1623 revalidation against the then-current vulnerability database → #1694 → #1691 → #1503 → #1486 final PostgreSQL contention/workspace/lease/security/review evidence. No additional Reply-SLA source mutation is justified by this central update.