Skip to content

chore: remove unavailable Veilance Market registry entry - #93

Closed
BlackAporia wants to merge 1 commit into
starkience:mainfrom
BlackAporia:remove-dead-veilance-market
Closed

chore: remove unavailable Veilance Market registry entry#93
BlackAporia wants to merge 1 commit into
starkience:mainfrom
BlackAporia:remove-dead-veilance-market

Conversation

@BlackAporia

@BlackAporia BlackAporia commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

Removes the registry entry for https://github.com/Portablelle/veilance-market and records the removal reason in registry-removals.json.

GitHub's API returns HTTP 404 for the repository. The unavailable entry currently makes shared registry validation reject unrelated registrations, including #86.

Validated locally with:

  • node scripts/validate-registry.mjs
  • HISTORY_REF=upstream/main node scripts/check-registry-retention.mjs

Both checks pass.

@BlackAporia

Copy link
Copy Markdown
Contributor Author

@starkience could you please review this removal? The repository is confirmed HTTP 404, both official registry checks pass, and this entry currently blocks valid registration #86 from appearing on the hackathon hub.

@BlackAporia

Copy link
Copy Markdown
Contributor Author

Bumping this: the dead Portablelle/veilance-market entry is still on main and every registration since Aug 17 10:54 (including GameShield #86, Oju #99, Aether #98, Stealth Checkout #97, ClaimLinks #95) is failing shared validation because of it — see #96. This PR is the only thing that unblocks the queue; the bot cannot apply it because it touches registry.json + registry-removals.json (2 files). A maintainer merge of this single removal PR would let the remaining registrations merge unattended.

starkience added a commit that referenced this pull request Aug 18, 2026
Portablelle/veilance-market answers 404. validate-registry.mjs checks every
entry in the file rather than the ones a pull request touches, so one dead
repository failed the whole registry and no registration could be applied -
eighteen open, nothing landed since 17 August, four teams reporting the same
wall on #86, #95, #97 and #98.

Applied from #93 by @BlackAporia, which recorded the removal correctly in
registry-removals.json so the retention check knows it was deliberate rather
than a merge dropping somebody.

The underlying flaw is separate and follows: a broken row that is already on
main must not be able to reject a registration that has nothing to do with it.

Co-authored-by: BlackAporia <116606427+BlackAporia@users.noreply.github.com>
@starkience

Copy link
Copy Markdown
Owner

Applied to main as 959dba2, with the removal recorded in registry-removals.json exactly as written here.

This was the entry blocking every open registration, and the queue moved as soon as it landed. The validator has also been changed so a broken row already on main is reported rather than failing somebody else's registration - thank you for the diagnosis, it was right.

@starkience starkience closed this Aug 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants