[JENKINS-49588] add readResolve method for 'usages' in Fingerprint.java

[mikecirioli]

add readResolve method to ensure that <usages ../> is always initialized properly when deserializing a fingerprint

See JENKINS-49588.

• It is not clear how this situation (a Fingerprint file without any usages being serialized to disk) is occuring, but this fix will prevent it from blowing up in the event that it does happen.

Proposed changelog entries

• Entry 1: Internal: Added readResolve method to Fingerprint.java to ensure the usages field is always initialized

Submitter checklist

• JIRA issue is well described
• Changelog entry appropriate for the audience affected by the change (users or developer, depending on the change). Examples
  * Use the Internal: prefix if the change has no user-visible impact (API, test frameworks, etc.)
• Appropriate autotests or explanation to why this change has no tests
• For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@reviewbybees @batmat @oleg-nenashev

[mikecirioli]

@oleg-nenashev - i have a couple of questions about this, i will follow up with you via email or chat.

[oleg-nenashev]

@reviewbybees it's on your plate

[batmat]

@mikecirioli I think a test (probably using @LocalData) is required here for completeness.

Also, added the WIP label. Please remember to remove (or ask for) it when you consider it ready for review.

[mikecirioli]

please remove the work-in-progress label, this PR is ready for reiew

[daniel-beck]

It is not clear how this situation (a Fingerprint file without any usages being serialized to disk) is occuring

I'd really like to see more investigation related to this. Either we ship 2.107.1 without this fix, or with it, and neither seems particularly appealing.

[mikecirioli]

@daniel-beck I agree, although I am not sure how to go about finding a way to reproduce it. I searched jira for any possibly related issues but found some issues with fingerprints being truncated due to "&" characters in text strings. If you have ideas for ways to recreate the root cause I am happy to investigate.

[batmat]

LGTM, cannot see how this could hurt, though agreed it would be better to understand where this comes from, if possible.

[oleg-nenashev]

@batmat @mikecirioli do you plan to merge it?

[batmat]

How about we add a WARNING in the if?

That could be useful to know if this a common issue, and in the future (if not everybody upgraded to this in the meantime, granted) this would be sent back through telemetry for Essentials.

[batmat]

I'll merge later today if nobody objects.

[daniel-beck]

Still lacking any understanding why this happens. Have we really made no progress there in the last five weeks?

[mikecirioli]

another person reported seeing this in JENKINS-49588, are we still planning to merge?

[daniel-beck]

Based on recent feedback in JENKINS-49588 it looks to me like we're lacking appropriate diagnostics for malformed fingerprint files. Is there a reasonable way to do that?

[oleg-nenashev]

@mikecirioli could you please respond to the question above?

[mikecirioli]

@daniel-beck @oleg-nenashev - this has dropped off my radar as of late. As far as I am aware we do not have a better understanding of why this is happening.

[mikecirioli]

Can we re-consider merging this PR? Even if we don't understand what is causing this issue, i am still seeing comments from people who are experiencing it. This PR should at least soothe some of that pain. I can add the warning that @batmat suggested if that will help us get some additional datapoints.

[oleg-nenashev]

I consider this pull request a harmless example of the protective code. It is not clear whether it addresses the reported issue, but it is definitely harmless as is. Since there is no movement expected here, I propose to merge it instead of closing

[oleg-nenashev]

@batmat @daniel-beck do you agree?

[batmat]

Yes, agree. At least it will help us triage the open JIRA: if the issue keeps coming after this merged, then this will already be an additional data point.

[oleg-nenashev]

OK. I will merge it into the next weekly if there is no negative feedback