Open briandealwis opened 6 years ago
I should note that this occurred during the upgrading process as part of ImportNativeAppEngineStandardProjectTest
where we coalesce our older containers into the new single master container.
I don't know that we can detect this situation. There are two solutions that I can think of:
Wrap the saveContainer()
within a try-catch, with the expectation that the container will be re-resolved in another situation (i.e., outside of a workspace notification) and so be able to write out the serialized container state.
Punt the container state serialization to a job. The danger is that we might might modify the container definition in the meantime so that the job would write out stale data.
Oops, wasn't finished. I should note that we've been doing (1) implicitly since we were silently swallowing the exception.
If the container is expected to be resolved eventually or frequently enough, I think (1) isn't a bad idea (also considering we've been doing so)?
As a follow-on to #3180, I noticed the following exception being logged.
This occurs in the following code:
We haven't noticed this problem previously because the classpath container was successfully resolved and set on the project.