Repository navigation
Serve addon definitions from the registry, not embedded data - #58
Merged
Merged
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## bump-gobl-v0.507.0 #58 +/- ##
======================================================
- Coverage 72.58% 72.56% -0.02%
======================================================
Files 47 48 +1
Lines 1988 1994 +6
======================================================
+ Hits 1443 1447 +4
- Misses 465 467 +2
Partials 80 80 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
GET /v0/addons/{key} returned 404 for every addon implemented in its own
module — mx-cfdi-v4, it-sdi-v1, pt-saft-v1, sa-zatca-v1, br-nfe-v4,
br-nfse-v1, dk-oioubl-v2, fi-finvoice-v3 and the three fr-ctc flows.
The handler read addons/<key>.json from core GOBL's embedded data
directory. Addons that moved out to their own modules register themselves
via init() when the bundle blank-imports them, but ship no file in that
directory, so only the addons still compiled into core resolved. The list
endpoint meanwhile reads the in-memory registry, so /v0/addons advertised
25 addons of which 12 could not be fetched.
Render the definition from the registry instead, via a new
ops.AddonData helper shared by the API and MCP server. This mirrors what
core GOBL's addons/generate.go does to produce those files, so output for
the addons still in core is byte-for-byte identical.
The same read was duplicated in the MCP addon tool and the
gobl://addons/{key} resource, and the gobl://addons resource listed the
embedded directory rather than the registry; all now go through the
helper.
Tests assert the invariant that broke — everything the registry reports
must be retrievable — so an addon moving out of core cannot regress this
again. They cover the API endpoint, both MCP paths, and the helper, and
the test packages now blank-import the bundle as the real binaries do;
without it no externally-implemented addon is registered and the gap is
invisible, which is how this shipped.
One deliberate behaviour change: /v0/addons/pl-favat-v2 no longer
resolves. It was a stale file left in core GOBL 0.505's data directory
for an addon that is not registered, so it was never listed by /v0/addons
and could not be used in a document's $addons. It is absent from core
GOBL 0.507 entirely.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
samlown
force-pushed
the
fix-external-addon-data
branch
from
September 17, 2026 11:25
b87d5ea to
e2e16c7
Compare
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
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.
Fixes
GET /v0/addons/{key}returning 404 for every addon implemented in its own module — e.g. https://gobl.dev/v0/addons/mx-cfdi-v4.The problem
handleAddonreadaddons/<key>.jsonfrom core GOBL's embeddeddatadirectory. Addons that moved out of core into their own modules (gobl.mx.cfdi,gobl.it.sdi, …) register themselves viainit()when the bundle blank-imports them, but they ship no file in that directory — so only addons still compiled into core resolved.The list endpoint reads the in-memory registry, so the two disagreed:
/v0/addonsadvertised 25 addons, 12 of which could not be fetched./v0/addonslists/v0/addons/{key}resolves404 before this change:
mx-cfdi-v4,it-sdi-v1,pt-saft-v1,sa-zatca-v1,br-nfe-v4,br-nfse-v1,dk-oioubl-v2,fi-finvoice-v3,fr-ctc-flow2-v1,fr-ctc-flow6-v1,fr-ctc-flow10-v1,pl-favat-v3.The fix
Render the definition from the registry via a new
ops.AddonDatahelper shared by the API and the MCP server. It mirrors what core GOBL'saddons/generate.godoes to produce those files, so output for addons still in core is byte-for-byte identical — verified against all 13 embedded files. No change for existing consumers.The same embedded read was duplicated in two more places, both fixed:
addontoolgobl://addons/{key}resourceand the
gobl://addonsresource listed the embedded directory rather than the registry, so it reported 13 keys where theaddon_listtool reported 25. It now uses the registry too.A side benefit: the handler no longer touches the filesystem at all, so the previous
path.Joinon user input is gone.Tests
The tests assert the invariant that actually broke — everything the registry reports must be retrievable — so an addon moving out of core cannot regress this silently again. Coverage spans the API endpoint, both MCP paths, and the helper.
Crucially, the test packages now blank-import the bundle as the real binaries do. Without it no externally-implemented addon is registered in the test binary and the gap is invisible — which is exactly how this shipped: the existing tests only ever checked
es-verifactu-v1, a core addon. Reverting the fix with the new tests in place fails on precisely the 12 affected addons.One deliberate behaviour change
/v0/addons/pl-favat-v2no longer resolves. It was a stale file left in core GOBL 0.505's data directory for an addon that is not registered, so it was never listed by/v0/addonsand could not be used in a document's$addons. It is absent from core GOBL 0.507 entirely, so it 404s there regardless.Notes
pl-favat-v3newly affected, since 0.507 drops its data file from core./v0/regimes/{code}is unaffected: all 32 registered regimes still live in core and resolve correctly. I checked.keyas a free-form string and only useses-verifactu-v1as an example, so behaviour now matches what the spec already promised.🤖 Generated with Claude Code