Repository navigation
Harden the metadata transform against long topics and newlines #9
Description
Activity
matt-edmondson commented
on Sep 8, 2026 ContributorAuthorMore actionsTriage
Priority: Low Effort: Small
What needs to be done: Harden the Terraform metadata transform against topics over GitHub's 50-character limit and multi-paragraph descriptions with embedded newlines — neither currently reachable by real repo content, but both cheap to guard.
Suggested next steps / acceptance criteria:
- Add a length guard/truncation for topics over 50 chars, with a fixture test over the limit
- Normalize newlines before sentence splitting in
desc_clean, with a multi-paragraph fixture test - Keep the existing 6 tests unchanged (they pin live GitHub values)
Blockers / dependencies: None identified
Generated by Claude Code
matt-edmondson commented
on Sep 22, 2026 ContributorAuthorMore actionsTriage
Not actionable in this repository — same cause as #8 and #7. Not assigning myself, nothing branched.
modules/metadatais not here.mainhas nomodules/directory and no Terraform content of any kind, so there is nodesc_cleanto normalize newlines in, no topic-length cap to add, and none of the 6 existing tests this issue is careful not to disturb.This is the third issue in the same cluster to stop at the same wall — #8 established on 2026-09-21 that its spec file has never existed on
maineither. The Terraform work is somewhere outside this repository.What would unblock this: say where the Terraform lives, or commit it. Until then #2, #3, #7 and #9 are dependents of #4 rather than independently actionable.
Worth keeping as written — both gaps are real and correctly described as unreachable by current repository content rather than as live defects, which is also why nothing is lost by them waiting.
Generated by Claude Code
matt-edmondson commented
on Sep 28, 2026 ContributorAuthorMore actionsDecision (maintainer, 2026-09-28)
Keep this issue, and move it to
ktsu-dev/infrastructurealong with the rest of the Terraform work (see #4). It transfers once the local branch is pushed.It overlaps KtsuBuild#170, which sanitizes topics on KtsuBuild's own
TAGS.mdsync. That issue is decided as: trim leading and trailing-, drop empty topics, keep the first 20 with a warning. Both paths push topics, so both keep a guard.Next reader: match that behaviour here so the two systems don't fight over a repo's topic list. That means the same leading-
-handling and the same 20 cap, in addition to this issue's 50-character and newline fixes.
Generated by Claude Code
matt-edmondson commented
on Sep 28, 2026 ContributorAuthorMore actions
Context
modules/metadataconverts each repo'sDESCRIPTION.mdandTAGS.mdinto a GitHub description and topic list. It has 6 passing tests and reproduces live GitHub values for 50 of 54 repos, with the 4 exceptions handled by explicit overrides.Two gaps are real but unreachable with current repository content. Neither is urgent. Both are cheap, and both fail in ways that are annoying to diagnose later.
Gap 1, no guard on GitHub's 50-character topic limit
The module caps topic count at 20 but never checks individual topic length. GitHub rejects topics over 50 characters with a 422, which would fail the apply for that repository.
Longest derived topic today is 32 characters (
round-trip-string-json-converter), so nothing currently trips it. A single long tag added to anyTAGS.mdwould.Gap 2,
desc_cleanstrips carriage returns but not newlinesEvery
DESCRIPTION.mdin the org is currently a single line. A future two-paragraph description would embed a newline,split(". ")would not see the.\nsentence boundary, and truncation would silently degrade to the word-boundary fallback instead of cutting on a sentence. The output stays valid, it just quietly gets worse.Acceptance criteria
Lower priority
There is also a whitespace edge case: the fallback returns
""if the first 349 characters are entirely whitespace. That is semantically the right answer for a whitespace-only file and is not worth code.