You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although no-isolation workers don't have any classloader isolation, they do have the requirement that they run in the same classloader as the task that submits them. We've recently discovered that there is a pathological case in composite builds where a worker can accidentally get a classloader from a different build in the composite (see #10317). We have a hacky fix for this in 5.6.1 (#10335), but we should come up with a better solution that aligns this requirement with how we communicate the classloader requirements for the classloader isolation and process isolation cases.
The text was updated successfully, but these errors were encountered:
Although no-isolation workers don't have any classloader isolation, they do have the requirement that they run in the same classloader as the task that submits them. We've recently discovered that there is a pathological case in composite builds where a worker can accidentally get a classloader from a different build in the composite (see #10317). We have a hacky fix for this in 5.6.1 (#10335), but we should come up with a better solution that aligns this requirement with how we communicate the classloader requirements for the classloader isolation and process isolation cases.
The text was updated successfully, but these errors were encountered: