fix(integrations): reject duplicate catalog IDs

[kriptoburak]

• A human has tested these changes.

---

Why

Catalog filenames are unique, but their hand-authored id values can collide. The generated JavaScript and Python lookups then become ambiguous, and the last entry silently wins.

Summary

• Reject duplicate integration IDs while building the catalog index.
• Report both conflicting catalog filenames.
• Avoid writing an invalid generated index.
• Add a regression test for the duplicate-ID path.

Issue Number

No linked issue. This is a focused catalog-integrity fix discovered while validating an integration contribution.

How to Test

HUMAN: No human test is claimed. Automated verification ran npm run build:integrations, uv run pytest -q tests/test_integration_catalog_in_sync.py (20 passed), and git diff --check.

To reproduce the guard, give two temporary catalog files the same id and run npm run build:integrations. The command must fail, name both files, and leave the generated index untouched.

Video/Screenshots

Not applicable. This changes a build-time validation error.

Notes

The rejected Xquik catalog entry is no longer in this PR. The final diff contains only the independent duplicate-ID invariant and its regression test.

[all-hands-bot]

👋 This PR needs a couple of things fixed before OpenHands can review it:

• the PR description's HUMAN: section needs at least 20 characters describing what you tested, not just the template placeholder

Push an update once this is addressed and this check re-runs automatically.

This is an automated check - no AI was used to generate this comment.

[all-hands-bot]

👋 This PR needs a couple of things fixed before OpenHands can review it:

• the PR description's HUMAN: section needs at least 20 characters describing what you tested, not just the template placeholder

Push an update once this is addressed and this check re-runs automatically.

This is an automated check - no AI was used to generate this comment.

[all-hands-bot]

👋 This PR needs a couple of things fixed before OpenHands can review it:

• the PR description's HUMAN: section needs at least 20 characters describing what you tested, not just the template placeholder

Push an update once this is addressed and this check re-runs automatically.

This is an automated check - no AI was used to generate this comment.

[kriptoburak]

Rebased onto current main and expanded the HUMAN test notes with the catalog checks that were run.

[enyst]

Hey @kriptoburak , thank you for the proposal!

I think at this time we are not ready to test and vouch for all third party potential integrations, and we don’t know nor use xquik, sorry. But since it has an MCP, and OpenHands supports MCP natively, users can always configure the MCP and run it, right?

[kriptoburak]

Thanks for the direction. I removed the Xquik catalog entry entirely and rebased onto current main. The PR now contains only the independent duplicate-integration-ID guard and its regression test; the targeted suite passes 20/20.

[kriptoburak]

@enyst The current head a7e6196e now fully follows your direction: it contains no Xquik integration or vendor catalog entry. The remaining 2-file diff is only a repository-native guard against duplicate hand-authored integration IDs plus its regression test (20/20 targeted tests pass).

I also restored the repository's PR-template sections and the required transparent HUMAN: test note without checking the human-tested box. When convenient, could you re-review the current focused head so the prior Xquik-specific change request no longer blocks this independent catalog fix?

[kriptoburak]

Thanks for the clear direction. Closing this integration proposal because OpenHands already supports MCP configuration natively and the project is not accepting third-party integrations it cannot test and vouch for. Keeping a dedicated Xquik extension here would not match the repository's maintenance policy.

[kriptoburak]

Correction: reopening because the current head is materially different from the reviewed integration proposal. a7e6196e contains no Xquik entry; it is the independent 2-file duplicate catalog-ID guard and regression test already documented above. The prior change request applies to commit 7d579596, not this focused head. Sorry for the mistaken closure; the current repository-native fix remains useful and ready for fresh review.

[kriptoburak]

@enyst Rebased the focused catalog-integrity fix onto current main at cde6638; current head is 5b40754f. The 2-file diff still contains no third-party integration entry. I strengthened the regression test to prove a duplicate ID leaves an existing generated index byte-for-byte unchanged, in addition to naming both conflicting catalog files.

npm run build, both sync checks, the 20-test integration-catalog suite, the full suite (556 passed, 12 skipped), and git diff --check pass locally. GitHub reports MERGEABLE; fork workflows await maintainer approval. The remaining CHANGES_REQUESTED review targets the superseded integration commit 7d579596, so the current independent guard is ready for a fresh review.