mengw15 opened a new issue, #6979: URL: https://github.com/apache/texera/issues/6979
### Task Summary `VFSURIFactory.decodeURI` returns a positional 4-tuple `(WorkflowIdentity, ExecutionIdentity, Option[GlobalPortIdentity], VFSResourceType)` ([VFSURIFactory.scala:50-83](https://github.com/apache/texera/blob/main/common/workflow-core/src/main/scala/org/apache/texera/amber/core/storage/VFSURIFactory.scala#L50)), and the Python port does the same ([vfs_uri_factory.py:44](https://github.com/apache/texera/blob/main/amber/src/main/python/core/storage/vfs_uri_factory.py#L44)). The Scala doc already advertises `@return A VFSUriComponents object`, but no such type exists. Nine production call sites destructure it positionally, so every caller has to remember the field order and most bind only one field: - **Scala** — `WorkflowExecutionsResource.scala:474`, `ExecutionResultService.scala:441` / `:527`, `DocumentFactory.scala:79` / `:122` / `:168`, e.g. `val (_, _, _, resourceType) = decodeURI(uri)` - **Python** — `document_factory.py:76` / `:119` / `:134`, e.g. `_, _, _, resource_type = VFSURIFactory.decode_uri(uri)` Plus ~22 destructurings across the Scala and Python test suites. Positional binding is easy to get wrong (nothing catches a swapped `_` position), and adding a field means touching every call site. **Fix:** introduce the named structure the doc already promises — a Scala `case class VFSUriComponents` and a matching Python `NamedTuple`/`dataclass` — so callers read `.resourceType` / `.resource_type`. Pure refactor, no behavior change, symmetric across both languages. ### Task Type - [x] Refactor / Cleanup - [ ] DevOps / Deployment / CI - [ ] Testing / QA - [ ] Documentation - [ ] Performance - [ ] Other -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
