Always post a comment, even when there's nothing to do - #16
Merged
Conversation
Root-caused a real user report ("workflow ran successfully but the
README didn't change") against a real PR: dakshcodez/gofiber-
starter-project#1. That repo is 100% Go, and docmend only parses
TypeScript/TSX/JavaScript/Python - parseCodebase() correctly found
zero chunks, so the pipeline correctly found nothing stale, but
never said so anywhere the PR author could see. Two early-return
paths in index.ts's run() only logged via core.info (visible in the
Action's own run logs, not on the PR) and exited silently - from the
PR's perspective: green checkmark, total silence, indistinguishable
from "didn't run at all."
This also directly matches the original design brief, which called
for a comment on every triggering PR, even the all-clear case
("3 sections verified accurate...") - not just when something needed
fixing.
Added postStatusComment (comment.ts) for the simple early-exit cases,
and restructured run() to always post something:
- Zero parseable code in the repo at all -> names which languages
are actually supported, rather than looking identical to "your
docs are fine."
- No relevant file changes (all excluded via .docmendignore) ->
says so.
- Changes detected but nothing stale -> distinguishes "nothing here
is linked to any doc" from "N sections checked, all still
accurate" - meaningfully different situations that both used to
produce identical silence.
Verified against the actual reported scenario, not a synthetic
stand-in: rebuilt a Go-only fixture matching the real PR's repo
composition, confirmed parseCodebase() genuinely returns zero chunks
for it (the real trigger condition), and confirmed
postStatusComment() posts the correct, specific message through a
mocked octokit.
Separately: Go support itself (or any language beyond the current
four) is a real feature gap, not something this commit addresses -
would need a new tree-sitter grammar, WASM build, and extraction
queries, comparable in scope to how TS/JS/Python were originally
added. Flagged for the user to prioritize separately.
- index.ts: moved the chunks.length === 0 check to right after
parseCodebase(), before parseDocs()/buildLinkGraph() run at all.
buildEmbeddingLinks() still calls llm.embed() once per doc section
regardless of how many code chunks exist to link against - so the
previous ordering meant every run of the exact scenario this PR
targets (a repo docmend can't parse) burned N Gemini embedding
calls before reporting "nothing to check." Checking first avoids
that entirely.
- index.ts: reworded both "nothing to check" messages that implied
a confident "your language isn't supported" diagnosis. Real gap
found during review: packages/core/src/parsing/queries.ts only
captures function_declaration/class_declaration/method_definition
- not arrow functions. A fully-supported TS/JS/React repo written
idiomatically (`const Foo = () => {...}`, extremely common for
components and hooks) can legitimately produce zero chunks despite
being a supported language, which would have made the original
wording actively wrong, not just unhelpfully silent. Messages now
acknowledge the ambiguity (unsupported language vs. a code pattern
not yet recognized) instead of confidently blaming the language.
Found by a fresh subagent review spawned after PR #16 was opened.
Verified the reordering doesn't change any other behavior (full
lint/typecheck/build still pass; the early-return still fires on the
same chunks.length === 0 condition, just before the now-skipped
parseDocs/buildLinkGraph calls instead of after).
Not fixed here, flagged as a separate, likely higher-priority gap
than adding a new language: the underlying arrow-function parsing
gap itself. Any TS/JS/React codebase built primarily on arrow
functions is currently under-covered by docmend's own "supported"
languages, not just genuinely-unsupported ones like Go.
4 tasks
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.
Summary
Root-caused from a real user report: "workflow ran successfully but the README didn't change" against dakshcodez/gofiber-starter-project#1. That repo is 100% Go, and docmend only parses TypeScript/TSX/JavaScript/Python -
parseCodebase()correctly found zero chunks, so the pipeline correctly found nothing stale, but never said so anywhere visible on the PR. Two early-return paths inindex.ts'srun()only logged viacore.info(Action run logs only, not the PR) - from the PR's perspective: green checkmark, total silence, indistinguishable from "didn't run at all."This also matches the original design brief, which specified a comment on every triggering PR, including the all-clear case.
What changed
Added
postStatusComment(comment.ts) and restructuredrun()to always post something:Test plan
parseCodebase()genuinely returns zero chunks for itpostStatusComment()posts the correct, specific message through a mocked octokitnpm run lint/typecheck/buildall passNot in scope here
Go (or any other language) support is a real feature gap, not something this PR addresses - would need a new tree-sitter grammar, WASM build, and extraction queries. Flagged separately for prioritization.