What happened?
When Texera/Amber is launched from a nested directory, the current amberHomePath detection can pick the wrong repository if the parent folder contains multiple sibling repos that also satisfy isAmberHomePath(...).
|
lazy val amberHomePath: Path = { |
|
val currentWorkingDirectory = Paths.get(".").toRealPath() |
|
// check if the current directory is the amber home path |
|
if (isAmberHomePath(currentWorkingDirectory)) { |
|
currentWorkingDirectory |
|
} else { |
|
// from current path's parent directory, search its children to find amber home path |
|
// current max depth is set to 2 (current path's siblings and direct children) |
|
val searchChildren = Files |
|
.walk(currentWorkingDirectory.getParent, 2) |
|
.filter((path: Path) => isAmberHomePath(path)) |
|
.findAny |
|
if (searchChildren.isPresent) { |
|
searchChildren.get |
|
} else { |
|
throw new RuntimeException( |
|
"Finding texera home path failed. Current working directory is " + currentWorkingDirectory |
|
) |
|
} |
|
} |
|
} |
For example, if the working directory is:
E:\texera\texera
the old logic moves up to:
E:\texera
and then scans children up to depth 2 using findAny(). If there are multiple valid matches under E:\texera, such as:
E:\texera\texeraE:\texera\a
the method may return a different matching repo instead of the one the process was launched from.
This causes Amber home path resolution to be nondeterministic / incorrect depending on directory layout.
How to reproduce?
-
Create a parent directory containing multiple repos that satisfy isAmberHomePath(...), for example:
E:\texera\texeraE:\texera\a
-
Launch Texera/Amber with the working directory set to E:\texera\texera.
-
Trigger code that evaluates amberHomePath.
-
Observe that the previous implementation may resolve the home path to E:\texera\a instead of E:\texera\texera.
Root cause
The previous implementation does this:
- if current working directory is not already the Amber home path
- walk the parent directory to depth 2
- return
.findAny() match
Because .findAny() does not prefer the current repo lineage, a sibling repo can be selected incorrectly.
Version
1.1.0-incubating (Pre-release/Master)
Commit Hash (Optional)
No response
What browsers are you seeing the problem on?
No response
Relevant log output
What happened?
When Texera/Amber is launched from a nested directory, the current
amberHomePathdetection can pick the wrong repository if the parent folder contains multiple sibling repos that also satisfyisAmberHomePath(...).texera/amber/src/main/scala/org/apache/texera/amber/engine/common/Utils.scala
Lines 39 to 59 in ac909a0
For example, if the working directory is:
E:\texera\texerathe old logic moves up to:
E:\texeraand then scans children up to depth 2 using
findAny(). If there are multiple valid matches underE:\texera, such as:E:\texera\texeraE:\texera\athe method may return a different matching repo instead of the one the process was launched from.
This causes Amber home path resolution to be nondeterministic / incorrect depending on directory layout.
How to reproduce?
Create a parent directory containing multiple repos that satisfy
isAmberHomePath(...), for example:E:\texera\texeraE:\texera\aLaunch Texera/Amber with the working directory set to
E:\texera\texera.Trigger code that evaluates
amberHomePath.Observe that the previous implementation may resolve the home path to
E:\texera\ainstead ofE:\texera\texera.Root cause
The previous implementation does this:
.findAny()matchBecause
.findAny()does not prefer the current repo lineage, a sibling repo can be selected incorrectly.Version
1.1.0-incubating (Pre-release/Master)
Commit Hash (Optional)
No response
What browsers are you seeing the problem on?
No response
Relevant log output