Page MenuHomePhabricator
Create Task
Maniphest T428917

Consider Stronger Post-Conditions on `realize()` and `fullyRealize()` Operations
Open, In Progress, HighPublic
Actions

Description

Description

The result of realize() or fullyRealize() is not always guaranteed to be a WFBase instance. This has ramifications for further applications of these operations, including idempotence. We also have to implement point-solutions to address downstream code that expects a WFBase but instead receives bare JSON. T426336 is probably a manifestation of this; also see TODOs tagged against this here task in function-orchestrator.

Desired behavior/Acceptance criteria (returned value, expected error, performance expectations, etc.)

  • consider enforcing the post-condition that realize() and fullyRealize() must always return a WFBase instance
  • no more broken
  • make WFReference.fullyRealize call fullyRealize on its result
    • audit other WFBase types in like fashion
  • setRealized() should enforce the same guarantees as resolve(), especially on sub-elements of complex types (WFObject, WFList)
    • setRealized should then be re-enabled for WFLists

Completion checklist

Related Objects

Event Timeline

cmassaro created this task.Jun 11 2026, 3:01 PM
cmassaro claimed this task.
cmassaro edited projects, added: Abstract Wikipedia team (26Q4 (Apr–Jun)); removed: Abstract Wikipedia team.
cmassaro moved this task from Incoming to In Engineering on the Abstract Wikipedia team (26Q4 (Apr–Jun)) board.
cmassaro mentioned this in T428835: widespread issues with Javascript processing Wikidata content.Jun 11 2026, 3:08 PM
cmassaro mentioned this in T428653: Orchestrator error logs from Monday 2026-06-08: Don't throw 'unidentified error' on evaluator 4xx responses.Jun 11 2026, 3:24 PM
DSantamaria changed the task status from Open to In Progress.Jun 15 2026, 1:25 PM
DSantamaria added a project: Essential-Work.
Jdforrester-WMF triaged this task as Medium priority.Jun 16 2026, 5:44 PM
cmassaro raised the priority of this task from Medium to High.Jun 17 2026, 6:18 PM
cmassaro updated the task description. (Show Details)
cmassaro updated the task description. (Show Details)Jun 22 2026, 3:27 PM
cmassaro added a comment.Jun 22 2026, 3:39 PM

A new test inspired by https://phabricator.wikimedia.org/T428914 has shown us a subtle source of bugs.

Calling setRealized on WFLists introduces problems when the internal objects have not been turned into WFBase objects. However, if we try to make the list elements into WFBase objects upon list creation, some scoping issues arise. We are relying on list elements being bound to a scope later in the function call. For now, I am writing a test that exercises this behavior, then "fixing" temporarily by disabling the setRealized operation on WFLists.

In the future, we may need to consider one of the following:

  • separating scope/wfConfig attachment from WFBase creation
    • this would allow us to make all of a list's elements into WFBase objects and setting their realized state without committing to a scope binding
  • deactivating setRealize entirely because it's a small optimization that introduces a lot of dangers
cmassaro mentioned this in T428914: "Abstract value error" that hasn't been there before.Jun 22 2026, 3:40 PM
Jdforrester-WMF edited projects, added: Abstract Wikipedia team (27Q1 (Jul–Sep)); removed: Abstract Wikipedia team (26Q4 (Apr–Jun)).Jul 1 2026, 4:59 PM
Jdforrester-WMF moved this task from Incoming to In Engineering on the Abstract Wikipedia team (27Q1 (Jul–Sep)) board.
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits