Repository navigation
Two TimescaleSupport doc sentences #3610 falsified are corrected: the job_history evidence read lives on StoreSelfMetrics with two callers, and an unlogged store still records FAILED runs (#3581 riders) - #3619
Merged
Conversation
… job_history evidence read lives on StoreSelfMetrics and has two callers, and an unlogged store still records FAILED runs (#3581 riders, #3582/#3574) Text only, no behavior. (1) The heaviest-refresh ceiling paragraph said the one shipped read touching job_history was DarlingStoreMetricsReader.JobHistoryEvidenceSql; #3610 moved the string to StoreSelfMetrics.JobHistoryEvidenceSql (the reader's is an alias) and gave it a second caller — the hourly self-metrics sweep runs it as the owner role and persists the count as an object_kind = 'job_history' row. (2) Both slot-watch alert texts said a store without timescaledb.enable_job_execution_logging "reports nothing there until it heals"; a FAILED run is written to job_history regardless of the GUC and only successes need it, so the lines now say a result holding no successful runs is the gap, not an empty view.
erikdarlingdata
enabled auto-merge (squash)
September 18, 2026 17:22
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — verified this is a text-only doc/log-message correction to TimescaleSupport.cs. Checked both factual claims against the code: DarlingStoreMetricsReader.JobHistoryEvidenceSql is literally = StoreSelfMetrics.JobHistoryEvidenceSql (an alias, pinned by DarlingMcpStoreMetricsToolsTests line 651), and StoreSelfMetrics.JobHistoryInsertSql/JobHistoryObjectKind confirm the second caller (hourly sweep persisting an object_kind = 'job_history' row as the job owner role). The corrected "FAILED runs are written regardless of the GUC" claim matches documented TimescaleDB job-execution-logging behavior. TimescaleDB support is Darling-only (Postgres-specific) with no Lite counterpart, so there's no parity drift. No SQL, security, or behavior changes.
erikdarlingdata
added a commit
that referenced
this pull request
Sep 19, 2026
…spliced once Fifty-nine PRs merged to dev today across the coordinator's lanes and the wave-2 worker's; each lane returned its entry to a buffer instead of touching this file, so that fifty-plus PRs did not each rebase the same twenty lines. This is the one splice. Every entry is one line (the archiver's compact() and the pins read them that way); riders fold into their parent's entry (#3599 under #3590, #3619 under #3611, #3623 under #3616, #3640 under #3633; #3617 test-only and #3661 re-cut as #3666 carry none); #3657's entry is in because it MERGED to dev - the twin to main is what is still pending. [Unreleased] gains a `### Added` above `### Fixed` (Keep-a-Changelog order) for the six new capabilities: per-user theme colours (#3606 / #3577 arm B), routed alert families (#3668 / #3598), the PostgreSQL logging audit tool (#3643 / #3607), the service-side wait sampler (#3645 / #3604), and the log-event classifier with its temp-file / autovacuum parser families (#3646 / #3601, #3664 / #3602 #3603). The other forty-eight are honesty fixes to existing surfaces and append to `### Fixed` after the wave-1 bullets, in PR-number order. Thirty-six reference definitions added for the issues the new entries cite and the index did not yet define; the [Unreleased] group is one ascending run again, which moves [#3557] into its slot (the one deleted line). Nothing under ## [3.8.0] or older is touched; the archive script was not run. One editorial touch: the #3585 entry ended in a dangling "Darling" and now reads "Darling only." (the tool exists only in the Darling MCP host). tools/changelog/changelog_archive.py verify: all PASS (1420 bold entries, floor 1,329; 1,358 distinct refs resolve; CRLF throughout; 356,539 bytes under the 750 KiB ceiling). ChangelogIndexAndArchiveTests: 5/5 pass via a net10.0 harness.
erikdarlingdata
added a commit
that referenced
this pull request
Sep 19, 2026
…spliced once (#3672) Fifty-nine PRs merged to dev today across the coordinator's lanes and the wave-2 worker's; each lane returned its entry to a buffer instead of touching this file, so that fifty-plus PRs did not each rebase the same twenty lines. This is the one splice. Every entry is one line (the archiver's compact() and the pins read them that way); riders fold into their parent's entry (#3599 under #3590, #3619 under #3611, #3623 under #3616, #3640 under #3633; #3617 test-only and #3661 re-cut as #3666 carry none); #3657's entry is in because it MERGED to dev - the twin to main is what is still pending. [Unreleased] gains a `### Added` above `### Fixed` (Keep-a-Changelog order) for the six new capabilities: per-user theme colours (#3606 / #3577 arm B), routed alert families (#3668 / #3598), the PostgreSQL logging audit tool (#3643 / #3607), the service-side wait sampler (#3645 / #3604), and the log-event classifier with its temp-file / autovacuum parser families (#3646 / #3601, #3664 / #3602 #3603). The other forty-eight are honesty fixes to existing surfaces and append to `### Fixed` after the wave-1 bullets, in PR-number order. Thirty-six reference definitions added for the issues the new entries cite and the index did not yet define; the [Unreleased] group is one ascending run again, which moves [#3557] into its slot (the one deleted line). Nothing under ## [3.8.0] or older is touched; the archive script was not run. One editorial touch: the #3585 entry ended in a dangling "Darling" and now reads "Darling only." (the tool exists only in the Darling MCP host). tools/changelog/changelog_archive.py verify: all PASS (1420 bold entries, floor 1,329; 1,358 distinct refs resolve; CRLF throughout; 356,539 bytes under the 750 KiB ceiling). ChangelogIndexAndArchiveTests: 5/5 pass via a net10.0 harness.
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.
Text-only follow-up to #3611 (merged 17:16Z); these two riders were granted for that PR but arrived after its auto-merge fired, so they ride a second PR off the same lane. No behavior changes; Storage builds at 0 warnings.
(1)
HeaviestHourlyRefreshObservedCeilingSeconds's doc, the job_history paragraph. It said the one shipped read touchingtimescaledb_information.job_historywasDarlingStoreMetricsReader.JobHistoryEvidenceSql. Since #3610 (#3582/#3574) that string lives onStoreSelfMetrics.JobHistoryEvidenceSql— the reader's member is an alias of it (DarlingMcpStoreMetricsToolsTestspins the equality) — and it has a second caller: the hourly self-metrics sweep runs it as the job OWNER's role and persists the count as anobject_kind = 'job_history'row, which is what makes the managed-moderecordingverdict a measurement. The sentence now names the home and both callers; the ownership-filter reasoning that follows it is unchanged.(2) The two slot-watch alert texts (
LogRefreshCeilingStalenessandLogHeaviestRefreshSlotHeadroomcarry the same sentence) said a store provisioned before the GUC's conf marker "reports nothing there until it heals". That overstates:job_historyrecords a FAILED run regardless oftimescaledb.enable_job_execution_logging; only successful runs need it. Both lines now say that with the GUC off only failed runs are written, so such a store shows the job's successes only once it heals, and a result holding no successful runs is the gap and not a quiet hour. The two pins on those lines (timescaledb_information.job_historyandenable_job_execution_loggingnamed) still hold.Also: nothing else. Rebased onto dev at
b6d60dde; touches onlyTimescaleSupport.csdoc text and two log-message strings.