Skip to content

fix: Added a shared in-progress VersionInfo returned to concurrent callers #2086

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
qcdyx wants to merge 3 commits into
base: master
Choose a base branch
from
Open

fix: Added a shared in-progress VersionInfo returned to concurrent callers #2086

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
cdc6638
Added a shared in-progress VersionInfo returned to concurrent callers…
qcdyx Jan 28, 2026
143b063
Merge branch 'master' into 2021-missing-validatorversion-value-from-g…
qcdyx Jan 29, 2026
26e4de7
formatted code
qcdyx Jan 29, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 10 additions & 1 deletion main/src/main/java/org/mobilitydata/gtfsvalidator/util/VersionResolver.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -43,6 +43,12 @@ public class VersionResolver {

private boolean resolutionStarted = false;

/**
* Keep a reference to the shared in-progress VersionInfo so concurrent callers don't get an empty
* instance.
*/
private volatile VersionInfo inProgressVersionInfo;
Copy link
Member

@davidgamez davidgamez Jan 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not convinced that this will fix the issue. The VersionResolver class is instantiated only once because it's a singleton bean, see. Making the class a singleton and synchronizing the resolve methods ensures that only one thread accesses the resolve method at any given time.

I think the issue is that the web validator makes an HTTP request to retrieve the version. When this HTTP call fails, the version number is returned as null. This is done in the Validator runner called from validateFeed method. If we set skipValidatorUpdate to true in the call, the VersionResolver will not do the HTTP call and the version will be resolved "locally". This will avoid any failures and guarantees that version numbers are consistently available.

Copy link
Contributor Author

@qcdyx qcdyx Feb 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll revisit this bug after stop_access schema update and feature addition.


public VersionResolver(ApplicationType applicationType) {
this.applicationType = applicationType;
}
Expand Down Expand Up @@ -92,7 +98,9 @@ public void onFailure(Throwable t) {
/** Starts release version resolution on a background thread. */
public synchronized VersionInfo resolve(boolean skipValidatorUpdate) {
if (resolutionStarted) {
return VersionInfo.empty();
// Return the shared instance (may already have currentVersion set), instead of a brand-new
// empty one.
return inProgressVersionInfo != null ? inProgressVersionInfo : VersionInfo.empty();
}
resolutionStarted = true;

Expand All @@ -102,6 +110,7 @@ public synchronized VersionInfo resolve(boolean skipValidatorUpdate) {
} catch (IOException ex) {
logger.atSevere().withCause(ex).log("Error resolving version info");
}
inProgressVersionInfo = versionInfo;

executor.submit(
() -> {
Expand Down
Loading