Skip to content

Prevent and clean up corrupted application links - #534

Draft
pathob wants to merge 1 commit into
release/1.xfrom
backport-1.x-applink-override-hardening
Draft

Prevent and clean up corrupted application links#534
pathob wants to merge 1 commit into
release/1.xfrom
backport-1.x-applink-override-hardening

Conversation

@pathob

@pathob pathob commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

Overriding an application link is a non-atomic delete and recreate. If the recreation failed, the instance was left with a registered application link ID without properties, causing repeated 'Link is corrupted' warnings. Now the original link is restored when the recreation fails, a missing application type module aborts the request before the delete, the OAuth configs are applied to the recreated link instead of the deleted instance, and an unknown UUID returns 404 instead of an NPE.

Already corrupted links cannot be retrieved through the applinks API: enumeration skips them, retrieval by ID throws
TypeNotInstalledException, and creating a link whose URL-derived ID collides with the remnant fails with 'already exists'. Deletion, however, only requires the ID, so a minimal ApplicationLink implementation carrying just the ID is enough to purge the remnant. Corrupted links are now cleaned up in all three paths: deleting by UUID purges an unretrievable link instead of failing with a 400, creating a link first removes a corrupted remnant registered under the ID derived from the rpc URL, and overriding by UUID purges and recreates the link from the supplied configuration.

(cherry picked from commit 91556ff)

Overriding an application link is a non-atomic delete and recreate. If
the recreation failed, the instance was left with a registered
application link ID without properties, causing repeated 'Link is
corrupted' warnings. Now the original link is restored when the
recreation fails, a missing application type module aborts the request
before the delete, the OAuth configs are applied to the recreated link
instead of the deleted instance, and an unknown UUID returns 404
instead of an NPE.

Already corrupted links cannot be retrieved through the applinks API:
enumeration skips them, retrieval by ID throws
TypeNotInstalledException, and creating a link whose URL-derived ID
collides with the remnant fails with 'already exists'. Deletion,
however, only requires the ID, so a minimal ApplicationLink
implementation carrying just the ID is enough to purge the remnant.
Corrupted links are now cleaned up in all three paths: deleting by
UUID purges an unretrievable link instead of failing with a 400,
creating a link first removes a corrupted remnant registered under the
ID derived from the rpc URL, and overriding by UUID purges and
recreates the link from the supplied configuration.

(cherry picked from commit 91556ff)
@sonarqubecloud

sonarqubecloud Bot commented Sep 3, 2026

Copy link
Copy Markdown

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.

1 participant