Updating an existing Application Link with a malformed URL causes an error

Issue Summary

If an existing application link has its 'Application URL' updated to a malformed URL (http:localhost, for example), this isn't checked and is simply accepted by the system and updated in the database. Then, when Jira is rebooted, the system will report errors when visiting the Application Link page in Jira.

This is reproducible on Data Center: yes

Steps to Reproduce

1. Create a working and functional Application Link in Jira. (For this example, I used another Jira server at http://localhost:8080)
2. Update the newly created Application Link so that the 'Application URL' is not correct (for example: http:localhost:8080)
   Note that Jira does not check the incorrect URL and just accepts it
3. Restart Jira

Expected Results

Jira should never have accepted the incorrect results, but it did. Now, after the reboot, we see the actual results below.

Actual Results

Upon rebooting Jira and returning to the Application Links page, the application link page no longer displays any application links at all (even if there are others which work just fine). Instead, there is an error message stating:

Something went wrong

The server returned a bad response.

You can try to refresh the page. If the error persists the application logs might provide additional information or you can reach out to your admin.

Closing the error message from the page still does not display any Application Links at all.

The below exception is thrown in the "atlassian-jira.log" file:

2022-05-05 15:00:40,786+1000 https-jsse-nio-49222-exec-25 ERROR admin 900x68x2 q4zvxm 0:0:0:0:0:0:0:1 /rest/applinks/3.0/applinks [c.a.p.r.c.error.jersey.ThrowableExceptionMapper] Uncaught exception thrown by REST service: java.lang.IllegalArgumentException: Schema specific part is opaque
com.google.common.util.concurrent.UncheckedExecutionException: java.lang.IllegalArgumentException: Schema specific part is opaque
	at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2050)
	at com.google.common.cache.LocalCache.get(LocalCache.java:3952)
	at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3974)
	at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4958)
	at com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4964)
	at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader.downloadInternal(AppLinksManifestDownloader.java:108)
	at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader.downloadNoEvent(AppLinksManifestDownloader.java:102)
	at com.atlassian.applinks.internal.capabilities.DefaultRemoteCapabilitiesService.updateAndGet(DefaultRemoteCapabilitiesService.java:290)
	at com.atlassian.applinks.internal.capabilities.DefaultRemoteCapabilitiesService.getCapabilitiesUnrestricted(DefaultRemoteCapabilitiesService.java:255)
<snip>

Full error stack attached.

Workaround

Currently, it it is only possible to correct this issue by interrogating and updating the database.

1. Run the following SQL against your database:

   SELECT
       propertyentry.id   AS id,
       property_key       AS key,
       propertyvalue      AS value
   FROM
       propertystring
   INNER JOIN
       propertyentry
   ON
       propertyentry.id = propertystring.id
   WHERE
       property_key LIKE 'applinks%rpc.url';
   

2. From the responses, you should see a list of applink URL's. Scan the list for the URL which is incorrect and copy that value.
3. Take a backup of your database as a precaution.
4. Run the following SQL command against your Jira database:

   UPDATE propertystring
   SET propertyvalue = '<correct_URL_of_the_app>'
   WHERE propertyvalue = '<incorrect_URL_from_previous_query>';
   

5. Restart Jira.

Once Jira is restarted, your application links should appear as normal. Even the one which was malformed. You can now edit or delete as needed. But, be sure to enter in the correctly formatted URL of the application or you may run into the same problem again.

This has been replicated in the currently oldest supported version of Jira 8.8.0 and the currently latest version of Jira 8.22.2. It is probably safe to assume that this issue exists in all versions in between.