René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Improve resilience of scijava-progress subsystem","articleBody":"With 5da81736cce48d7525e69762d51165c5e74735df, I removed the progress reporting from the `DefaultOpEnvironment`'s op discovery, because it was failing the `OpRegressionTest` on one of my systems. Investigation shone light onto three distinct issues, the first of which is that the `Progress` data structure gets confused about subtasks when a task gets orphaned:\r\n\r\n```\r\njava.lang.ExceptionInInitializerError: Exception java.lang.IllegalStateException:\r\nTask OpEnvironment: Discovering Ops has subtasks that did not complete!\r\n```\r\n\r\nThis condition arises in the `Task#complete()` method when `tasksDefined \u0026\u0026 progress() != 1.0 \u0026\u0026 current.longValue() == max.longValue()`. One theory is that this happens when previous attempts at `DefaultOpEnvironment` environment construction fail, leaving orphaned `Task` objects hanging out in the `ThreadLocal\u003cArrayDeque\u003cTask\u003e\u003e progressibleStack` data structure, such that later tasks on the same thread end up erroneously reasoning that they must then be subtasks of those orphaned tasks. But the evidence is not quite a slam dunk match to that theory, because: 1) I checked the number of pending subtasks in my failing scenario and it is 3 rather than 1, which seems suspicious; and 2) the first failing environment construction must be due to some other reason than previously orphaned task—that is, the first task must get orphaned some other way than this sort of cascading task failure. Which brings us to #229...","author":{"url":"https://github.com/ctrueden","@type":"Person","name":"ctrueden"},"datePublished":"2024-05-30T15:51:27.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/228/scijava/issues/228"}