Skip to content

Fix 500 when every wiki page link fails to resolve - #24770

Open
jtauschl wants to merge 2 commits into
opf:devfrom
jtauschl:fix/wiki-page-links-empty-metadata-sql-crash
Open

Fix 500 when every wiki page link fails to resolve#24770
jtauschl wants to merge 2 commits into
opf:devfrom
jtauschl:fix/wiki-page-links-empty-metadata-sql-crash

Conversation

@jtauschl

@jtauschl jtauschl commented Aug 14, 2026

Copy link
Copy Markdown

Ticket

n/a

Summary

Fixes the crash described in OP-19928 (points 2 and 3 of that report -- point 1's original framing about identifier semantics has been corrected in a follow-up comment there and does not apply to this fix).

When every link's identifier fails to resolve via the page-info query, metadata ends up empty. enrich_models still tried to build a LEFT JOIN (VALUES #{placeholders}) with zero placeholders, producing the invalid SQL fragment LEFT JOIN (VALUES ) and crashing with a Postgres syntax error, instead of returning the links with a nil title (which is what already happens for any individual link whose resolution fails when at least one other link in the same request succeeds).

Change

Return the relation directly with a NULL title column when metadata is empty, matching the shape callers already get from the non-empty path.

Test plan

  • Added a regression spec covering the case where every page link fails to resolve
  • Verified live against a real 17.7.1 instance: before the fix, GET on a work package with one unresolvable-identifier link returned 500; after the fix, it returns 200 with the link's title absent

When every link's identifier fails to resolve via the page-info query,
metadata ends up empty; enrich_models still tried to build a
LEFT JOIN (VALUES #{placeholders}) with zero placeholders, producing
the invalid SQL fragment "LEFT JOIN (VALUES )" and crashing with a
Postgres syntax error instead of returning the links with a nil title
(which is what happens for any individual link whose resolution
fails when at least one other link in the same request succeeds).

Return the relation directly with a NULL title column when metadata
is empty, matching the shape callers already get from the non-empty
path.
@github-actions

github-actions Bot commented Aug 14, 2026

Copy link
Copy Markdown

All contributors have signed the CLA ✍️ ✅
Posted by the CLA Assistant Lite bot.

@jtauschl

Copy link
Copy Markdown
Author

recheck

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes a Postgres syntax error (500) in the wiki page link metadata enrichment path when all page-link identifiers fail to resolve, by avoiding construction of an invalid LEFT JOIN (VALUES ) fragment and instead returning links with a NULL title column (matching the “partial failure” behavior).

Changes:

  • Add an early return in PageLinkMetadataService#enrich_models to select NULL AS title when the metadata list is empty.
  • Add a regression spec covering the “all links fail to resolve” scenario, asserting the service does not raise and returns all links with nil titles.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
modules/wikis/app/services/wikis/page_link_metadata_service.rb Returns a relation with a NULL title column when no metadata rows are available, preventing invalid SQL.
modules/wikis/spec/services/wikis/page_link_metadata_service_spec.rb Adds regression coverage for the “all page links unresolvable” case (no crash, nil titles preserved).

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment on lines +89 to +94
it "returns the relation without raising, instead of crashing on an empty VALUES clause" do
expect { service.call }.not_to raise_error

service_result = service.call
expect(service_result).to be_success
end
service.call was invoked once inside expect { ... }.not_to raise_error
and again to capture the result -- the second call re-ran the same
service logic (a real, if idempotent, side effect) purely to get a
value the first call had already produced.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants