Repository navigation
release: scheduler re-seed fix (#2975) + draft-integrity SQLite guard - #2978
Merged
Merged
Conversation
…SQLite) cds.fiori.draft_admin_integrity: true requires DB-level ON DELETE CASCADE constraints on every draft table's DraftAdministrativeData_DraftUUID FK (generated as .hdbconstraint, HANA-only — see srv/lib/draft-integrity-preflight.js, which is explicitly isHanaKind-gated). Unit tests run under the `development` profile on in-memory SQLite, where those constraints do not exist. Without the cascade, activating a draft leaves the active row with HasDraftEntity=true and DELETE(IsActiveEntity=true) returns 403 DRAFT_ACTIVE_DELETE_FORBIDDEN_DRAFT_EXISTS. This is universal to every draft-enabled entity (reproduced on Missions as well as GridTemplates), not a per-test cleanup gap — the discard-then-delete band-aid in #2909 only passed where the delete sat in a swallowed afterAll. Scope the flag off under [development] only. hybrid (--profile hybrid) and production run on HANA and keep the flag ON, so the optimized-deletion behavior that #2909 depends on is unchanged in every environment that has the constraints. Fixes the puzzle-grid-templates unit failure introduced by the CAP 10.2 upgrade.
…s-draft-delete-flake fix(cap): disable draft_admin_integrity under [development] profile (SQLite)
CAP 10.2.0 made the `.every().as()` singleton completion delete-then-reseed guarded: the next occurrence is recreated only if CAP's own delete of the status='processing' row removed it (_cnt > 0). runWithLock's #1021 belt-and-suspenders deleted that same row in its finally on every tick, racing CAP's complete-tx; when our delete won, CAP saw _cnt=0, treated the task as unscheduled concurrently, and skipped re-seeding — so every scheduled job ran once then never rescheduled until a process restart. Harmless pre-10.2 (next occurrence was recreated unconditionally), fatal from 10.2 on. Remove the per-tick deleteStuckOutboxRow call (and its now-unused import); CAP 10.2 already guarantees exactly-once deletion in its complete-tx. Genuine mid-flight tombstones remain covered by scheduler-reaper.js and the operator forceUnwedge action (which still uses deleteStuckOutboxRow). Tests updated to assert the row is NOT deleted per tick while JobLastRun still records.
…seed-2975 fix(scheduler): stop deleting singleton outbox row per tick (#2975)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Emergency release — PROD scheduler outage
Promotes DEV→main to fix the ~day-long PROD scheduler outage.
Included (DEV ahead of main)
.every().as()completion only recreates the next occurrence if CAP's own delete removed thestatus='processing'row (_cnt>0). Our#1021per-tickdeleteStuckOutboxRowdeleted that same row inrunWithLock's finally, racing CAP's complete-tx → when ours won, CAP skipped re-seeding → every job ran once then never rescheduled until a restart. Removed the per-tick delete; CAP 10.2 already does exactly-once deletion.draft_admin_integrityunder [development] profile (SQLite). Unrelated DEV fix riding along in this release.Test plan
metrics-rollupholds true 5-min cadence across ≥2 cycles with NO restart (DB-clock staleness:SECONDS_BETWEEN(lastSuccessAt, CURRENT_UTCTIMESTAMP))