The first time I restarted the pod with that env var I saw it log the following: • “173319.255 [main] INFO c.linkedin.metadata.boot.UpgradeStep:42 - Attempting to run UpgradeDefaultBrowsePathsStep Upgrade Step..” • “173319.241 [main] INFO c.l.metadata.boot.BootstrapManager:33 - Executing bootstrap step 13/13 with name UpgradeDefaultBrowsePathsStep...” • “173519.596 [main] INFO c.l.m.b.s.UpgradeDefaultBrowsePathsStep:54 - Upgrading batch 0-5000 out of 0 of browse paths for entity type dataset” • “173754.394 [main] INFO c.l.metadata.boot.BootstrapManager:33 - Executing bootstrap step 13/13 with name UpgradeDefaultBrowsePathsStep...” • “173754.394 [main] INFO c.linkedin.metadata.boot.UpgradeStep:42 - Attempting to run UpgradeDefaultBrowsePathsStep Upgrade Step..”

So the first time through it got to a point where it found 0 Browse Paths to upgrade for entity type “dataset” (which shouldn’t be true, we have tens of thousands of datasets that all need to be upgraded) and then it never hits any log line along that path again (not even on the second attempt).

I tried restarting it twice and I only got the “Attempting to run UpgradeDefaultBrowsePathsStep Upgrade Step..” and “Executing bootstrap step 13/13 with name UpgradeDefaultBrowsePathsStep” log lines on each of them with no re-attempt and it never reaching the “Upgrading batch” line.

I don’t see any other log messages that seem relevant, is there anything I can look out for? Any ideas on how to proceed would be appreciated 🙏

one other thing that seems fishy that could conceivably be related is that after upgrading, each entity returned from the entities browse endpoint

/entities?action=browse

includes that entities

urn

value as it’s

name

, which I’m fairly sure wasn’t happening prior to the upgrade. If i view the entity in the entitiesV2 endpoint though, the name is still showing up correctly 🤷 Does this bug sound familiar at all? I couldn’t find anybody else reporting similar

Hey all, just wanted to follow up here in case anybody else runs into similar. We finally got that migration to succeed. For us, the migration was lengthy, and the gms health check endpoint returned a 500 status until it completes. Using the default readiness prob settings, this caused our java process to get killed on the first run of the migration. On the relaunch (and on all subsequent launches) the migration would not run again, because as a first step (before actually migrating anything) the migration adds a record to the db to tell it not to run again on future launches. For us it wasn’t obvious that the process got killed, a new process was started on the same pod and we didn’t end up capturing anything about the process being terminated in our logs. We just saw “busy connection” errors that turned out to be a side effect of the pool shutting down when the process received a kill signal. To get the migration to run we overrode the readiness and liveness probe with an initialDelaySeconds of 1200 and it succeeded (but YMMV, this will depend on how many records you have to migrate). If your migration ran once already and failed, deleting the record with urn ‘urnlidataHubUpgrade:upgrade-default-browse-paths-step’ from the metadata_aspect_v2 table will remove the marker telling it that it already ran before and allow it to try again.