fix(lotw): confirmations never applied - duplicate qsl_lotw_date assignment (42601)#218
Merged
Merged
Conversation
The dynamic UPDATE seeded qsl_lotw_date = NOW()::date and then appended a second qsl_lotw_date assignment whenever LoTW returned qsl_rcvd_date (which it nearly always does with qso_qsl=yes). Postgres rejects two assignments to the same column in one UPDATE (42601), so the first matched confirmation threw, the whole download was logged failed, and confirmations were never applied. - Assign qsl_lotw_date exactly once: LoTW's qsl_rcvd_date when present, otherwise today. - Isolate per-row apply failures (try/catch + counter) so one bad row can no longer discard an entire batch; surface a failure summary in lotw_download_logs.error_message and the response. - Advance the incremental cursor only from successfully applied confirmations, and use stations.lotw_last_qsl_rcvd_date as qso_qslsince for non-manual downloads (the column was written but never read back). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This was referenced Jul 13, 2026
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes LoTW download confirmation application failures caused by generating an invalid UPDATE statement (duplicate qsl_lotw_date assignment), which previously caused Postgres error 42601 and prevented any confirmations in a batch from being applied. The PR also improves sync reliability for scheduled/automatic runs by introducing incremental fetching and isolating per-confirmation apply errors.
Changes:
- Ensure
qsl_lotw_dateis assigned exactly once during confirmation updates (prefer LoTW QSL date, else today). - Add per-row
try/catchwhen applying confirmations so a single failing update doesn’t discard the whole batch; summarize partial failures intolotw_download_logs.error_messageand API response. - Use
stations.lotw_last_qsl_rcvd_dateasqso_qslsincefor non-manual downloads and only advance the cursor based on confirmations that actually applied.
When conf.qsl_rcvd_date was missing we wrote NOW()::date to the contact but never recorded it in appliedQslDates, so lotw_last_qsl_rcvd_date never advanced and incremental downloads refetched the same history. Compute the fallback date in JS and record it like any other applied date. Addresses Copilot review feedback on #218. Co-Authored-By: Claude Fable 5 <noreply@anthropic.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
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.
Problem
"LoTW confirmations never come back." The bulk download route builds a dynamic
UPDATE contacts SET ...that assignedqsl_lotw_datetwice — seeded asNOW()::dateand appended again with LoTW'sqsl_rcvd_date(returned for nearly every confirmation whenqso_qsl=yes). Postgres rejects multiple assignments to the same column in one UPDATE (error 42601), so the first matched confirmation threw, the outer catch marked the whole downloadfailed, and every confirmation in the batch was discarded. Downloads have been silently failing whenever there was anything to apply.Fix
qsl_lotw_dateexactly once: LoTW's own QSL date when present, else today.lotw_download_logs.error_messageand the response.stations.lotw_last_qsl_rcvd_date) only from confirmations that actually applied, and read it back asqso_qslsincefor non-manual downloads — the column was maintained but never used, so cron downloads re-fetched the full history every run. (The QSL-since date is deliberately NOT applied to the local contacts filter: confirmations arrive for arbitrarily old QSOs.)Verification
npm run lint/npm run typecheck/npm run buildclean.🤖 Generated with Claude Code