Skip to content

fix: stamp updated_by on bulk tag edits and background reclassification - #3261

Open
claudiaboldis wants to merge 1 commit into
mainfrom
fix/serenity-updated-by-not-stamped-on-tag-edits
Open

fix: stamp updated_by on bulk tag edits and background reclassification#3261
claudiaboldis wants to merge 1 commit into
mainfrom
fix/serenity-updated-by-not-stamped-on-tag-edits

Conversation

@claudiaboldis

Copy link
Copy Markdown
Contributor

Summary

Two live prompt-tag-mutation paths never stamp updated_by/updated_at, leaving the field pointing at whoever created the prompt (or unknown) even after a real edit:

  • Bulk tag assign/remove (bulk-tags-job.js): callerId reached the request handler (acceptParsedBulkTags) but was never included in the job metadata sent to createAndEnqueueJob. The worker (bulkTagsHandler) then mutated tags via updatePromptTagsByIds with no authorship-stamping call anywhere.
  • Background reclassification (classify-prompts-job.js, reclassifyExisting): same shape — patches a prompt's tags (to inject its resolved intent value) via updatePromptTagsByIds, no stamp call, and the self-requeue chain (requeuePending) didn't carry callerId forward either.

Both now thread callerId through job metadata and, after a successful tag write, make the same best-effort authorship-stamp call the CSV-import edit path already uses (buildUpdateMetadata + patchPromptsMetadataBatch, see applyUpsertTagWrites in prompts.js): the tag write is the point of the operation, so a failed stamp is logged, not fatal — it must never discard tag changes the caller already got a successful response for.

Found while investigating a separate, historical updated_by null-count question (pre-brandalf migration prompts — unrelated, one-time gap). These two are a distinct, live gap on the edit side.

Changes

  • src/support/serenity/handlers/bulk-tags-job.js: enqueue callerId in job metadata; worker stamps authorship on every prompt it actually updates.
  • src/support/serenity/handlers/classify-prompts-job.js: requeuePending takes and forwards callerId; reclassifyExisting reads it (default 'unknown' for jobs enqueued before this existed), stamps authorship per project after a successful tag patch, and carries callerId into any further self-requeue.
  • Tests added for both: stamp-on-success, default-to-unknown, no-stamp-when-nothing-changed / when-the-tag-write-failed, and best-effort behavior when the stamp call itself fails.

Test plan

  • npx eslint clean on all four changed files
  • Targeted suite (bulk-tags-job.test.js + classify-prompts-job.test.js): 46/46 passing
  • Full npm test (lint + full suite + coverage thresholds): passing

Introduced by: N/A

Bulk tag assign/remove (bulk-tags-job.js) dropped callerId on the floor
between the request handler and the enqueued job, and the worker mutated
prompt tags via updatePromptTagsByIds with no authorship-stamping call at
all. Background reclassification (classify-prompts-job.js) had the same
gap when patching a prompt's tags to inject its resolved intent value.

Both now thread callerId through job metadata and follow the same
best-effort stamp pattern already used by the CSV-import edit path
(applyUpsertTagWrites in prompts.js): the tag write is the point of the
operation, so a failed authorship stamp is logged, not fatal.

Found while investigating a separate historical updated_by null-count
question (pre-brandalf migration prompts) — these two are a distinct,
live gap on the edit side, not a historical one.
@codecov

codecov Bot commented Sep 10, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants