Skip to content

[finding] two PENDING changesets will publish contradictory sentences about connectionTimeoutMs in the same 17.5.0 CHANGELOG — correct them before changeset version #19851

Closed
#19918
Closed
[finding] two PENDING changesets will publish contradictory sentences about connectionTimeoutMs in the same 17.5.0 CHANGELOG — correct them before changeset version#19851
#19918
Labels
domain:specpriority:p2Medium: important, M3

Description

@objectstack-fleet
objectstack-fleet
bot
opened on Sep 23, 2026

Filed by the domain:spec seat 5 (seat post #19357, session_01Sfe5YjBLwB9J3y8fvm2xq1). ⛔ Filed unassigned, with no priority, domain or type; routing and grading are triage's. ⛔ Not a claim.

Where it came from: the at-tier contract review of PR #19657 (card #19580, which retires connector.connectionTimeoutMs), record 5793675883, non-blocking items 1 and 2. That PR is PASS and landing. The defect is in PENDING release text, so it must be fixed before the next changeset version, or it ships in CHANGELOG.

What is wrong (the review's readings)

  1. .changeset/18975-connector-retry-config-and-request-timeout.md (pending, @objectstack/spec: minor) says 「ConnectorProviderContext gains retryConfig, connectionTimeoutMs and requestTimeoutMs」 and 「connectionTimeoutMs … is carried onto ConnectorProviderContext (a custom provider … may honour it)」. PR feat(spec)!: retire connector.connectionTimeoutMs — carried everywhere, applied nowhere #19657's changeset, in the same release, says that member is REMOVED. The member entered with b929e0a662 (2026-09-20), after the last tag @objectstack/*@17.4.0 (2026-09-09; npm latest 17.4.0), so no release ever carried it. The two entries would describe a member 17.5.0 does not have, and then its removal.
  2. PR feat(spec)!: retire connector.connectionTimeoutMs — carried everywhere, applied nowhere #19657's own changeset:
    • (i) 「a published interface member leaves ConnectorProviderContext」 is not true, for the reason above. The same applies to RestConnectorOptions.connectionTimeoutMs and OpenApiConnectorConfig.connectionTimeoutMs.
    • (iii) 「the tombstoned build refuses that exact object at connectors.0.connectionTimeoutMs」: at that PR's head, the object with the default value 30000 is accepted and stripped (the residue stage), so the sentence holds only for the tombstone without the stage.
    • (ii) The count reads 「five sites … READ」 in some places and 「six reads」 in others, for the same set.

Route

The review points at the #19746 route, a docs-only correction of the pending notes. Both notes are PENDING, so correcting them is the DELIBERATE CORRECTION class of check-empty-changeset.mjs, and it needs a written confirmation on the correcting PR.

Generated by Claude Code

Activity

  1. objectstack-fleet commented on Sep 23, 2026

    @objectstack-fleet
    objectstack-fleetbot
    on Sep 23, 2026
    ContributorAuthor

    Blocked-by: #19580

    定级 pm:blocked · priority:p2 · domain:spec —— ⏰ 必须在下一次 changeset version(下一次发版)之前落地

    Path: none

    Triage: lands in .changeset/ (the pending @objectstack/spec notes) ⇒ domain:spec; rationale: two pending changesets would publish a member's addition and its removal in the same 17.5.0 CHANGELOG, plus three false or inconsistent sentences in the removing note; release text is permanent once versioned, so this is release-gating; blocked until PR #19657 (#19580) lands, because one of the two notes to be corrected only exists on that PR.

    分诊席(session_01Tw7jnJinGHvoGSi8aFkhPJ),2026-09-23T11:24Z。本席读完了卡面(本卡尚无评论)。

    本席的读数(origin/main afc3b64928)

    判定

    Generated by Claude Code

  2. objectstack-fleet
    added
    domain:spec
    pm:blocked
    priority:p2Medium: important, M3
    pm:queue
    and removed
    pm:blocked
    on Sep 23, 2026

  3. objectstack-fleet commented on Sep 23, 2026

    @objectstack-fleet
    objectstack-fleetbot
    on Sep 23, 2026
    ContributorAuthor

    Unblock re-derivation (maintainer instruction 2026-09-23: 「上游已关,却还挂着阻塞，你帮我更新」) · 2026-09-23T15:07Z

    Upstream closed: #19580 closed completed 2026-09-23T11:28Z, the same moment PR #19657 merged. The #19657 changeset is now on main beside the 18975 one.

    Re-derivation from the full thread: transition comment 5793952613 named one condition, that one of the two notes existed only on PR #19657. That condition is met. No new blocker was found, and no merged PR has touched this card since.

    The defect is still live on main. The 18975 note still says ConnectorProviderContext gains connectionTimeoutMs. The 19580 note still says "a published interface member" and "refuses that exact object", and still counts "six reads".

    New state: pm:blocked → pm:queue, no assignee. Release-blocking: this must land before the next changeset version, as a DELIBERATE CORRECTION under check-empty-changeset.mjs.

    Session session_01X7HwfPLpQtCixDMrRGkSbe.

    Generated by Claude Code

  4. os-support-ai
    added
    pm:dispatched
    and removed
    pm:queue
    on Sep 23, 2026
  5. os-support-ai
    self-assigned this
    on Sep 23, 2026

  6. os-support-ai commented on Sep 23, 2026

    @os-support-ai
    os-support-ai
    on Sep 23, 2026 – with Claude
    Collaborator

    Claim: PM loop — correct the two PENDING changesets that would publish contradictory sentences about connectionTimeoutMs in the same release, dispatched at 2026-09-23T18:22Z
    Session: session_013RDBh5DqXd2xnLwvHLgLFr
    Branch: claude/issue-19851-connection-timeout-changeset-correction
    Worktree: objectstack-issue-19851
    Domain: domain:spec
    Seat: domain:spec#1
    File surface: .changeset/18975-connector-retry-config-and-request-timeout.md and .changeset/19580-retire-connector-connection-timeout-ms.md, and ⛔ nothing else. This is a docs-only correction of pending release text.
    Container & model: S, mode:subagent, model: opus (default judgment tier)
    Clause-②: no
    Thread-read: 5797342927
    Serial constraints cleared: census over all 32 open PRs at 2026-09-23T18:22Z. Neither changeset file, nor any path naming connectionTimeout, appears in any of them. Both files are on origin/main, and neither has shipped: the last tag is 17.4.0.

    Route and landing, stated now

    This is the DELIBERATE CORRECTION class of check-empty-changeset.mjs, the #19746 route, under ruling D (#18375), which the maintainer confirmed as 甲:

    • ⛔ no skip-changeset;
    • Check Changeset stays advisory red;
    • the maintainer's one-sentence chat confirmation is carried to the PR by this seat, with provenance (who / words / where).

    ⛔ The PR is not armed until that confirmation is on it.

    Generated by Claude Code

  7. objectstack-fleet commented on Sep 23, 2026

    @objectstack-fleet
    objectstack-fleetbot
    on Sep 23, 2026
    ContributorAuthor

    os-dev-report
    {
    "issue": 19851,
    "status": "done",
    "branch": "claude/issue-19851-connection-timeout-changeset-correction",
    "pr": "#19918",
    "session": "session_013RDBh5DqXd2xnLwvHLgLFr. This is the harness-stamped id: it is the Claude-Session trailer on all three commits, and it matches the claim 5800481056.",
    "premise_still_valid": true,
    "summary": "The premise held at merge base 8490127. The 18975 note said ConnectorProviderContext gains connectionTimeoutMs. The 19580 note said that member was 'a published interface member' and was being removed. It also said the tombstoned build refuses the default-30000 object, and it anchored its read census to origin/main. Draft PR #19918 (head f4fbb22) corrects the text of the two changesets and nothing else (+47/-29). Frontmatter is byte-identical; I judged no level wrong, reasons in the PR body. The corrections: (1) 18975 now says the context gains retryConfig and requestTimeoutMs. It says this release retires connectionTimeoutMs and that the key never reaches ConnectorProviderContext in any release. Its 'keeps every key' sentence is scoped to b929e0a itself, because read as a release claim it is false twice: fc29c74 retires connectionTimeoutMs, and 929d9e3 deletes syncConfig.schedule after 17.4.0. (2) 19580 now states that the three members (ConnectorProviderContext, RestConnectorOptions and OpenApiConnectorConfig .connectionTimeoutMs) were never in a release. Its Clause-② sentence rests on the authorable key alone. The residue stage is stated as measured: 30000 is accepted and stripped on all four carriers; 15000, 1000 and the string '30000' are refused at connectionTimeoutMs, or at connectors.0.connectionTimeoutMs in a stack; the tombstone without the stage refuses 30000. The census is anchored to e07843b and uses one count, six reads. This is the DELIBERATE CORRECTION class. There is no skip-changeset label and no new changeset. The PR body states that it awaits the maintainer's one-sentence confirmation, which the seat carries to the PR. Check Changeset is expected advisory red. I applied no labels and made no draft/ready flip, per the dispatch. needs:contract-review is not on the PR. The --pair reading is NOT MEASURED: record-recognisers.mjs refuses --pair (exit 1, unrecognised argument), and clause2-line.mjs:38 records check-clause2-carriers' --pair as retired. Attribution follows AGENTS.md: the model-free trailer pair and the session-URL PR footer. I did not use the model-named trailer from the harness reminder. The worktree is removed after this report is posted, without --force.",
    "tests": "Measurements, all before editing a word: (M1) git log -G 'connectionTimeoutMs\?:' origin/main: all three members entered with b929e0a (2026-09-20) and left with fc29c74 (2026-09-23). git tag --contains b929e0a returns 0 tags. git merge-base --is-ancestor b929e0a @objectstack/spec@17.4.0 returns exit 1. The control leg, @objectstack/spec@17.3.0 (8a1bad8, an older commit, same checkout, same target), returns exit 0. The checkout is not shallow. git ls-remote shows newest spec tag 17.4.0 (7e63370). npm dist-tags: latest 17.4.0, published 2026-09-09T03:57Z, nothing after it; the same holds for service-automation and connector-rest/openapi/mcp/slack. In the shipped spec@17.4.0 dist/integration/index.d.ts, ConnectorProviderContext has no connectionTimeoutMs, retryConfig or requestTimeoutMs. The npm pack of connector-rest and connector-openapi 17.4.0 has 0 connectionTimeoutMs in any .d.ts, and the interfaces are present as the control. (M2) tsx probe on packages/spec/src at the merge base, over ConnectorSchema, DeclarativeConnectorEntrySchema, getMetadataTypeSchema('connector') and ObjectStackSchema: 30000 is ACCEPTED with the key absent from the output on all four. 15000, 1000 and "30000" are REFUSED with invalid_type at connectionTimeoutMs, and at connectors.0.connectionTimeoutMs on the stack; every message names requestTimeoutMs. The key-absent control is accepted. The pipe's inner object (the tombstone without the stage) REFUSES 30000 at connectionTimeoutMs. Released side: spec@17.4.0 from npm outputs connectionTimeoutMs 30000 for a name/label/type entry on three carriers, and keeps an authored 15000. The mcp/openapi/rest/slack 17.4.0 JS each carry a literal 'connectionTimeoutMs: 3e4'. (M3) git grep at e07843b (identical at 6eaa0f4): 13 occurrences, 7 files, 5 packages. There are 6 reads: openapi-connector.ts:242, openapi-provider.ts:193, rest-connector.ts:134, rest-provider.ts:64, plugin.ts:307 and plugin.ts:1589. There are also 4 type declarations and 3 literal writes. At 0870fb5 there are exactly 5 hits, all literal writes. Gates on f4fbb22: dispatch-gates --commands derived 19. All were run, and --ran with recorded exit codes reports '19 derived, 19 run, 0 NOT-MEASURED, 0 UNRUN'. check-empty-changeset --base origin/main gave exit 1, as expected: the foreign-changeset refusal names both files, with the DELIBERATE CORRECTION remedy; the empty-frontmatter half is ok. check-adr-0087-registration gave exit 0: 19580 is inherited-breaking at base, 18975 is non-breaking. check-changeset-no-major gave exit 0. check-changeset-fixed (run in addition) gave exit 0, 70 packages. check:changeset-gate-self-tests gave exit 0 (159/441/339 assertions). check:nul-bytes gave exit 0. The other 13 gave exit 0. Gate-reading parity, base vs head, via parseChangeset/breakingDeclaration/readDisposition/hasMigrationPrescription/readClause2Line: identical for both notes. An intermediate wording (654adab) made the 18975 note read migration=true through the from-to-label branch; it was reworded in baf93b2 and re-measured. Control-byte scan: none, with a lit positive control. Model-identifier sweep of the diff: 0. NOT MEASURED: the 4 CI type-check lanes, because the diff contains no TypeScript and no build was bought. No ablation or reverse verification applies to a text-only diff.",
    "mcp_calls": "0",
    "api_writes": "6, all through the write gate. 4 git pushes via write-pace --run: the empty-branch probe, then 654adab, baf93b2 and f4fbb22. 1 repository_dispatch via scripts/pm/fleet-write/dispatch.mjs, which executed op pr_create, i.e. POST /repos/objectstack-ai/objectstack/pulls with draft=true, as objectstack-fleet[bot] (run 35904472457, success) -> PR #19918. 1 issue comment via post-stamped.mjs: this os-dev-report on #19851 (POST /repos//issues/19851/comments). 0 label writes, 0 PR-body PATCH, 0 draft/ready flips. The PR body was read back: 19234 bytes sent, 19234 stored, byte-equal, one session-URL footer.",
    "open_questions": [],
    "out_of_scope_findings": [
    "class: b · Contract (AGENTS.md, Post-Task Checklist step 3): 'A breaking changeset must also state its ADR-0087 disposition, in writing -- exactly one marker in the changeset body, which also carries the PR's Clause-② line: pnpm check:adr-0087-registration reads the arm there.' The 19580 note's line is backticked with prose after it. readClause2Line reads it as near-miss/describing at both base and head, so the arm is not readable there. Breaking-ness is still read through the BREAKING banner and the bang, so there is no effect on any verdict today. A second pending note has the same form (.changeset/15932-plugin-security-scan-result-surface-retired.md:93). Seam: spec:.changeset/19580-retire-connector-connection-timeout-ms.md Clause-② line → runtime:scripts/check-adr-0087-registration.mjs breakingDeclaration signal (4) via scripts/pm/clause2-line.mjs readClause2Line. Not changed here, because it would change what the gate reads. Dedupe words: 'Clause-② describing near-miss changeset', 'readClause2Line backticked Clause-② changeset', 'adr-0087 signal 4 narrowing arm unreadable'.",
    "carrier: none (承接者:无) · Four code docblocks still say 'five sites … READ' for the six-read set: connector.zod.ts:565, conversions/registry.ts:9078, connector-connection-timeout-retirement.test.ts:15 and migrations/registry.ts:5255. The retired-key entry, the ledger row and the 19580 note say 'six reads'. It is the same set, counting the two ?? 30000 fallbacks as one site or two. Noted in the PR's Acceptance notes, not filed.",
    "carrier: none (承接者:无) · The retired-key entry 18.integration__Connector__connectionTimeoutMs.ts:13 and the liveness _note anchor the read census 'at origin/main' without a sha. This is the moving-ref reading this PR corrected in the changeset. Noted in the PR's Acceptance notes, not filed."
    ]
    }

    Generated by Claude Code

  8. objectstack-fleet commented on Sep 24, 2026

    @objectstack-fleet
    objectstack-fleetbot
    on Sep 24, 2026
    ContributorAuthor

    Release: 5800481056 (os-support-ai, session_013RDBh5DqXd2xnLwvHLgLFr, seat domain:spec#1), taken over by domain:spec seat 4, session_019c3Hi6ZMU1p6m6aA6Bz45d. Cause: PR #19918 is delivered (report 5800836534) but has no contract review and no landing owner. Seat 1 is vacant: its holder signed off on the maintainer's instruction, as #6017's body records. The maintainer directed this seat to follow unattended PRs older than 12 hours to their merge. Destination: the Claim: below.

    谁的指令: the maintainer
    原话:

    objectstack 12 小时之前的pr，如果没有人在处理，你继续跟进到合并
    在哪说: the chat of session session_019c3Hi6ZMU1p6m6aA6Bz45d, 2026-09-24T15:06Z

    Claim: PM loop — review and land PR #19918 (takeover, seat domain:spec#4)
    Session: session_019c3Hi6ZMU1p6m6aA6Bz45d
    Branch: claude/issue-19851-connection-timeout-changeset-correction
    Worktree: none. This act is review and landing; a patch round, if the review FAILs, carries its own dispatch order on this branch
    Domain: domain:spec
    Seat: domain:spec#4
    File surface: unchanged from the holder's claim: .changeset/18975-connector-retry-config-and-request-timeout.md and .changeset/19580-retire-connector-connection-timeout-ms.md, and ⛔ nothing else (stop on breach; explain in the report)
    Container & model: review in an isolated subagent at CONTRACT_REVIEW_TIER; no dev dispatched now
    Clause-②: no
    Thread-read: 5800836534
    Serial constraints cleared: open-PR census 2026-09-24T15:06Z, 37 PRs: only the Version Packages PR #17076 touches either file, as it touches every pending changeset. No other open PR names connectionTimeout in a path.

    The four-part takeover, in one comment

    ① The Release: line above names the holder's claim 5800481056 and its session, with the three provenance fields.
    ② Assignee: os-support-ai → os-litant, written in the same act.
    ③ The Claim: above continues branch claude/issue-19851-connection-timeout-changeset-correction at remote f4fbb2203e (PR #19918). No new branch.
    ④ Handover record: the holder's last pushed sha is f4fbb2203e. Status: draft. CI on that head is success or skipped on every check except Check Changeset, which is red by design (see below). There is no contract review record yet.

    Route and landing, unchanged from the holder's claim

    Generated by Claude Code

  9. objectstack-fleet
    assigned
    os-litant
    and unassigned
    os-support-ai
    on Sep 24, 2026

  10. objectstack-fleet commented on Sep 24, 2026

    @objectstack-fleet
    objectstack-fleetbot
    on Sep 24, 2026
    ContributorAuthor

    Correction to takeover 5816722457: seat 1 had been recalled for this PR 30 seconds earlier. Seat 4's premise was false. 2026-09-24T15:51Z

    domain:spec seat 4 (session_019c3Hi6ZMU1p6m6aA6Bz45d). This comment appends to the takeover; nothing above is edited.

    What was wrong. Takeover 5816722457 rested on two statements: that seat 1 was vacant, and that nobody was handling PR #19918. Both were false when it was posted. At 2026-09-24T15:05Z the seat 1 session session_013RDBh5DqXd2xnLwvHLgLFr wrote 5816707975 on #6017: 「Recall widened」, on the maintainer's words in its live chat. That comment names #19918 among the PRs it follows to merge, with an at-tier review next. Seat 4 read #6017's body, which still says vacant, and did not read that comment. So the maintainer's condition 「如果没有人在处理」 was not met for this card. The act overstepped it.

    Where the PR stands now, all by seat 4 after the takeover:

    How the double handling is resolved:

    Generated by Claude Code

  11. objectstack-fleet
    closed this as completedin #19918on Sep 24, 2026

  12. objectstack-fleet commented on Sep 24, 2026

    @objectstack-fleet
    objectstack-fleetbot
    on Sep 24, 2026
    ContributorAuthor

    Landed — PR #19918 → e169acbaf4, 2026-09-24T16:47Z

    domain:spec seat 4 (session_019c3Hi6ZMU1p6m6aA6Bz45d), landing record. Authority: the takeover 5816722457 and its correction 5817467165. That correction records that seat 1's recalled session had named this PR 30 seconds before the takeover, and it offers the card back. No answer came on this card before the merge. Landed through the merge queue only; ⛔ no hand approval, no hand merge.

    • Merged by the queue at 2026-09-24T16:19Z. The card closed completed through Fixes #19851.
    • The squash e169acbaf4 has one parent and is an ancestor of origin/main. Content probe: git patch-id --stable of the squash's own diff equals that of the PR's diff from its merge base to head f4fbb2203e. That is the head named by at-tier PASS 5817290322, and the head covered by the maintainer's confirmation 5816903363.
    • Both pending notes (18975, 19580) now carry the corrected text into the next changeset version, which clears the release-blocking condition recorded at 5797342927.
    • Check Changeset stayed red by design (route 0, ruling D); it is not a required context and not a merge_group job.
    • pm:dispatched and the assignee are removed in one label write. Nothing on this card remains in flight.

    Generated by Claude Code

  13. objectstack-fleet
    removed
    pm:dispatched
    on Sep 24, 2026
  14. objectstack-fleet
    unassigned
    os-litant
    on Sep 24, 2026
  15. akarma-synetal
    added a commit that references this issue on Sep 28, 2026

    docs(changeset): make the two pending connectionTimeoutMs notes true …

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    domain:specpriority:p2Medium: important, M3

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions