Repository navigation
learn: retrospective learnings - #500
peco-engineer-bot[bot] wants to merge 24 commits into
Conversation
Signed-off-by: peco-engineer-bot[bot] <peco-engineer-bot[bot]@users.noreply.github.com>
Signed-off-by: peco-engineer-bot[bot] <peco-engineer-bot[bot]@users.noreply.github.com>
Signed-off-by: peco-engineer-bot[bot] <peco-engineer-bot[bot]@users.noreply.github.com>
Signed-off-by: peco-engineer-bot[bot] <peco-engineer-bot[bot]@users.noreply.github.com>
Signed-off-by: peco-engineer-bot[bot] <peco-engineer-bot[bot]@users.noreply.github.com>
|
Thanks for your contribution! To satisfy the DCO policy in our contributing guide every commit message must include a sign-off message. One or more of your commits is missing this message. You can reword previous commit messages with an interactive rebase ( |
Signed-off-by: peco-engineer-bot[bot] <peco-engineer-bot[bot]@users.noreply.github.com>
|
Thanks for your contribution! To satisfy the DCO policy in our contributing guide every commit message must include a sign-off message. One or more of your commits is missing this message. You can reword previous commit messages with an interactive rebase ( |
Signed-off-by: peco-engineer-bot[bot] <peco-engineer-bot[bot]@users.noreply.github.com>
|
Thanks for your contribution! To satisfy the DCO policy in our contributing guide every commit message must include a sign-off message. One or more of your commits is missing this message. You can reword previous commit messages with an interactive rebase ( |
Signed-off-by: peco-engineer-bot[bot] <peco-engineer-bot[bot]@users.noreply.github.com>
|
Thanks for your contribution! To satisfy the DCO policy in our contributing guide every commit message must include a sign-off message. One or more of your commits is missing this message. You can reword previous commit messages with an interactive rebase ( |
Signed-off-by: peco-engineer-bot[bot] <peco-engineer-bot[bot]@users.noreply.github.com>
|
Thanks for your contribution! To satisfy the DCO policy in our contributing guide every commit message must include a sign-off message. One or more of your commits is missing this message. You can reword previous commit messages with an interactive rebase ( |
There was a problem hiding this comment.
Verdict: 1 Low
Documentation-only PR: it appends dated retrospective learning sections to .claude/knowledge/learning-log.md, with no executable code to review. One low-severity doc-consistency issue — the appended ## Entries section leaves the stale "No learnings have been recorded yet" preamble in place, now contradicted by the content below it (also missing a blank line before the heading). Otherwise looks good.
|
|
||
| No learnings have been recorded yet — the first retrospective PR will append the | ||
| initial dated section below. | ||
| ## Entries |
There was a problem hiding this comment.
🔵 Low — This PR appends the first ## Entries section directly beneath the preamble paragraph that still reads "No learnings have been recorded yet — the first retrospective PR will append the initial dated section below." Since this is that first retrospective PR and it now adds many dated sections, the sentence immediately above ## Entries is false the moment this merges — a reader sees "no learnings recorded yet" followed by 20+ learning sections.
When the retrospective flow writes the initial section, it should also replace (or drop) that placeholder sentence so the preamble no longer contradicts the content below it.
Minor secondary nit on the same line: ## Entries is appended with no blank line separating it from the preceding paragraph. CommonMark lets an ATX heading interrupt a paragraph so it still renders, but a blank line before the heading is the house style elsewhere in this file and avoids renderer-specific surprises.
Signed-off-by: peco-engineer-bot[bot] <peco-engineer-bot[bot]@users.noreply.github.com>
|
Thanks for your contribution! To satisfy the DCO policy in our contributing guide every commit message must include a sign-off message. One or more of your commits is missing this message. You can reword previous commit messages with an interactive rebase ( |
|
|
||
| No learnings have been recorded yet — the first retrospective PR will append the | ||
| initial dated section below. | ||
| ## Entries |
There was a problem hiding this comment.
🔵 Low — The preamble right above the new ## Entries heading still says "No learnings have been recorded yet". This PR adds 17 dated sections, so that sentence is now wrong. The author flow reads this file back as knowledge, so it will see a statement that contradicts the rest of the file. Also, ## Entries comes straight after the paragraph with no blank line in between. Most Markdown renderers still treat it as a heading, but markdownlint (MD022) flags it, and it doesn't match the spacing used elsewhere in the file. Replace the stale sentence (for example, "Dated sections are appended below.") and add a blank line before ## Entries.
Signed-off-by: peco-engineer-bot[bot] <peco-engineer-bot[bot]@users.noreply.github.com>
|
Thanks for your contribution! To satisfy the DCO policy in our contributing guide every commit message must include a sign-off message. One or more of your commits is missing this message. You can reword previous commit messages with an interactive rebase ( |
There was a problem hiding this comment.
Verdict: 1 Medium · 1 Low · 1 Nit
The learning log is mostly fine as a docs-only update, with one medium issue: the 2026-09-24 entry contradicts the later 2026-10-06 entry on how to handle empty-string catalog arguments. Separately, the lockfile resolved-URL rule now appears three times (2026-09-01, 2026-09-09, 2026-10-07); merging those into one entry would keep the log tidier (nit).
Other findings
- ⚪ Nit — This rule tells bot workflows to set
queue: maxon the concurrency group. I couldn't verifyqueueagainst GitHub's documentedconcurrencykeys (group,cancel-in-progress), and nothing in this diff shows where it comes from. If the key isn't supported, a workflow written from this rule could fail validation or quietly ignore it. Either confirm the key exists and cite the workflow that uses it, or remove it from the rule.
| - **Context:** PR #528 (upgrade SQL kernel to 1.1.0) — the only signal that the kernel changed its `User-Agent` contract from *append-to-base* to *replace-base* (so the connector's `NodejsDatabricksSqlConnector/...` prefix must now be SEA-allow-listed) was buried in the regenerated `native/kernel/index.d.ts` JSDoc diff; hand-authored comments in `lib/kernel/KernelAuth.ts` still described the old append semantics and went stale. | ||
| **Rule:** On a native/kernel binding version bump, read the regenerated binding-doc (`index.d.ts` JSDoc) diffs for silently-changed runtime contracts, and update any hand-authored comments that duplicate those contracts — a mocked unit suite will not catch a server-side behavior change like UA allow-listing, so verify it against a live warehouse before release. | ||
| - **Context:** PR #528's regenerated kernel docs specify that `listSchemas`/`listColumns` treat an **empty-string catalog as matching nothing** (non-empty catalogs stay exact), while the driver forwards `request.catalogName` verbatim with no `''`→`undefined` normalization — so an empty-string catalog yields zero rows on the kernel path versus wildcard-like behavior on Thrift, and it's untested (unlike `getPrimaryKeys`, which explicitly rejects `''`). | ||
| **Rule:** Kernel and Thrift metadata calls diverge on empty-string filter args (kernel: empty catalog matches nothing; Thrift: wildcard); normalize `''`→`undefined` when wildcard semantics are intended and add a test asserting the empty-catalog behavior on the kernel backend. |
There was a problem hiding this comment.
🟡 Medium — This rule from 2026-09-24 says to normalize ''→undefined on the kernel metadata path, and its context says getPrimaryKeys "explicitly rejects ''". The 2026-10-06 entry (line 129) says the opposite: PR #537 removed that guard, and the rule there is to forward empty strings unchanged and never coerce them in just one backend. The author flow reads this log back as rules, so the bot gets two contradictory instructions for the same code path. Mark the older entry as superseded, or reword it so it matches the later decision. For example: note that empty-catalog semantics differ, and say to document that rather than normalize it.
|
|
||
| No learnings have been recorded yet — the first retrospective PR will append the | ||
| initial dated section below. | ||
| ## Entries |
There was a problem hiding this comment.
🔵 Low — The preamble still says "No learnings have been recorded yet — the first retrospective PR will append the initial dated section below". Directly after it, this PR adds ~170 lines of learnings. There is also no blank line before ## Entries, so the heading comes right after a paragraph. Remove or reword the stale sentence and add a blank line before the heading.
(Anchored to the nearest changed line — see the description for the exact location.)
Signed-off-by: peco-engineer-bot[bot] <peco-engineer-bot[bot]@users.noreply.github.com>
|
Thanks for your contribution! To satisfy the DCO policy in our contributing guide every commit message must include a sign-off message. One or more of your commits is missing this message. You can reword previous commit messages with an interactive rebase ( |
There was a problem hiding this comment.
Verdict: 1 Medium · 1 Low · 2 Nit
This PR only adds to the learning log; there is one medium concern. The 09-24 and 10-06 sections give opposite rules for empty-string catalog handling, so the author bot reading the log could follow either. The other findings are low: a stale placeholder sentence, one rule repeated three times, and one rule that needs a qualifier.
Other findings
- ⚪ Nit — The intro still says "No learnings have been recorded yet — the first retrospective PR will append the initial dated section below." That stops being true once this PR adds entries. Also,
## Entries(L13) comes straight after the paragraph with no blank line. Please delete or reword the placeholder sentence and add a blank line before the heading. - ⚪ Nit — The same rule appears three times: lockfile
resolvedURLs must point atregistry.npmjs.org, not an internal proxy or mirror (2026-09-01 L87, 2026-09-09 L95, 2026-10-07 L133). The repeats make the log longer without adding anything, and they make it harder to spot rules that actually differ. Please merge them into one rule and list all three PRs (#516/#522/#538) in its context.
| - **Context:** PR #528 (upgrade SQL kernel to 1.1.0) — the only signal that the kernel changed its `User-Agent` contract from *append-to-base* to *replace-base* (so the connector's `NodejsDatabricksSqlConnector/...` prefix must now be SEA-allow-listed) was buried in the regenerated `native/kernel/index.d.ts` JSDoc diff; hand-authored comments in `lib/kernel/KernelAuth.ts` still described the old append semantics and went stale. | ||
| **Rule:** On a native/kernel binding version bump, read the regenerated binding-doc (`index.d.ts` JSDoc) diffs for silently-changed runtime contracts, and update any hand-authored comments that duplicate those contracts — a mocked unit suite will not catch a server-side behavior change like UA allow-listing, so verify it against a live warehouse before release. | ||
| - **Context:** PR #528's regenerated kernel docs specify that `listSchemas`/`listColumns` treat an **empty-string catalog as matching nothing** (non-empty catalogs stay exact), while the driver forwards `request.catalogName` verbatim with no `''`→`undefined` normalization — so an empty-string catalog yields zero rows on the kernel path versus wildcard-like behavior on Thrift, and it's untested (unlike `getPrimaryKeys`, which explicitly rejects `''`). | ||
| **Rule:** Kernel and Thrift metadata calls diverge on empty-string filter args (kernel: empty catalog matches nothing; Thrift: wildcard); normalize `''`→`undefined` when wildcard semantics are intended and add a test asserting the empty-catalog behavior on the kernel backend. |
There was a problem hiding this comment.
🟡 Medium — These two rules contradict each other. The 2026-09-24 rule says to normalize ''→undefined on kernel metadata calls, and its context (L116) says getPrimaryKeys "explicitly rejects ''". The 2026-10-06 rule (L129) says the opposite: PR #537 removed that guard, and identifiers, including the empty string, should be forwarded unchanged with no coercion in either backend.
The author flow reads this log back as guidance (author.knowledge_log), so it can follow whichever rule it reads first. Please mark the 09-24 rule as superseded by the 10-06 one, or reword it so it no longer recommends normalizing and no longer says getPrimaryKeys rejects ''.
| - **Context:** In CONNECTION_PARAMETERS.md (PR #509), the Azure OAuth / `token` / `staticToken` rows were repeatedly set to `✅` on the Kernel cell when the option is actually inert on some flows (e.g. `useDatabricksOAuthInAzure` is inert on U2M), forwarded only on one arm, or uses a different mechanism than Thrift — reviewers flagged the same `✅`-should-be-`⚠️` error across four rows. | ||
| **Rule:** In the backend-support tables, use `⚠️` (not `✅`) for any option that is only partially honored or behaves differently between Thrift and kernel — inert on a flow, forwarded on only one arm, or divergent host/mechanism handling; reserve `✅` for uniformly honored-and-forwarded options, and make the rendered cell match the PR description's stated `❌→⚠️` intent. | ||
| - **Context:** PR #509 introduced a version-gating doc claim that the pinned `0.2.0` native binding "rejects" `authMode: 'AzureSpM2m'`, but the committed napi type surface `native/kernel/index.d.ts` declares `AzureSpM2m` in its `AuthMode` enum — the assertion was neither verifiable from the repo nor consistent with the checked-in binding definition. | ||
| **Rule:** Don't assert runtime behavior of pinned/published native binaries that isn't observable from this repo; treat the committed napi `.d.ts` as the source of truth for which modes the binding declares, and use conditional phrasing ("confirm your installed build supports X") rather than a hard "the binding rejects it" claim when shipped-binary behavior can't be verified from source. |
There was a problem hiding this comment.
🔵 Low — These two rules partly conflict. The 2026-08-25 rule says to "treat the committed napi .d.ts as the source of truth for which modes the binding declares". The 2026-08-28 rule says the same file has been hand-edited and can drift from the real native ABI, and that it says nothing about what the shipped binding actually supports. Please qualify the 08-25 rule: the .d.ts is the source of truth only when it was regenerated from the pinned KERNEL_REV, and even then it doesn't show what the published npm binary supports.
Rolling retrospective learnings
This PR accumulates one dated section of learnings per day (from merged PRs and engineer-bot author runs) until it is merged; merging it starts a fresh one. The bot never writes the canonical log directly.
Latest update 2026-11-07: 3 new learning(s) since 2026-11-06T17:24:26Z.