Don't no-op DELETE for cache-evicted Postgres scans - #32
Draft
cursor[bot] wants to merge 1 commit into
Draft
Conversation
get() and list() already serve SaaS job history from Postgres after RAM
eviction, but delete() returned False without touching the DB whenever the
job was missing from the in-memory cache. DELETE /jobs/{id} then returned
204 while the scan row stayed in scan_jobs and reappeared on the next list.
Co-authored-by: dmitryflynn <dmitryflynn@users.noreply.github.com>
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
1 participant
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.
Bug and impact
On the Postgres/SaaS backend,
GET /v1/jobs/{id}andGET /v1/jobsserve cache-evicted history fromscan_jobs.DELETE /v1/jobs/{id}did not.Trigger: A completed scan ages out of the 500-job / 12h in-memory cache (or was never on this API instance). The user still sees it in the job list, deletes it, and gets 204. The Postgres row is untouched, so the scan reappears on the next list/get. Historical scans cannot actually be deleted.
Root cause
JobManager.delete()returnedFalseas soon asjob_idwas missing from_jobs, so it never calleddelete_sync(). That was correct when get/list were cache-only. After the PG fallback was added, a cache miss became the common case for SaaS history, not a reason to skip the durable delete.Cache eviction (
_evict_only=True) is unchanged: it still drops RAM only and keeps the durable row.Fix
User deletes always call
delete_sync()on the Postgres path, even when the job is not in the in-memory cache. JSON-backend behavior is unchanged.Validation
test_delete_cache_evicted_job_removes_postgres_row— evicted job is removed from the store and subsequentget()is Nonetest_evict_only_does_not_delete_postgres_row— capacity/TTL eviction still keeps the durable rowtest_delete_missing_postgres_job_returns_falsetest_jobs_sse.pystill pass