morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[PR #7216] fix(update): report Frida native module readiness #7722

New issue

Open

opened 2026-11-03 13:39:53 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-03 13:39:53 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/7216
Author: @dakjdakd
Created: 10/26/2026
Status: 🔄 Open

Base: main ← Head: fix/update-frida-readiness

📝 Commits (2)

7ddb692 fix(update): report Frida readiness after verified updates
7577e30 fix(update): retain Frida loader diagnostics and integrate main

📊 Changes

8 files changed (+588 additions, -7 deletions)

View changed files

📝 docs/installation.md (+18 -7)
📝 src/application/Update.test.ts (+63 -0)
📝 src/application/Update.ts (+15 -0)
📝 src/application/UpdateRuntime.ts (+9 -0)
➕ src/domain/OptionalProviderReadiness.ts (+20 -0)
➕ src/frida/FridaBindingReadiness.ts (+153 -0)
➕ tests/boundary/process/fridaBindingReadiness.test.ts (+309 -0)
📝 tests/process-global/cliLogging.test.ts (+1 -0)

📄 Description

Summary

Fixes #3556.

rea update now reports whether the identified installation's Frida native module can load, separately from whether the CLI update succeeded. A missing or unloadable optional module keeps a verified update successful and returns its actual diagnostic together with a manual recovery command when the resolved Frida package provides an install script. Running the command again on an already-current installation checks readiness again without reinstalling.

Problem and expected behavior

The updater deliberately passes --ignore-scripts to npm and Bun. That preserves its existing lifecycle boundary, but Frida 17.23.2 obtains its native binding through an install script rather than shipping the binding in its package tarball. Verifying only the new CLI's version therefore allows a successful update to leave Frida unusable without explaining the problem until a later Frida operation.

Issue #3556 establishes the published 6.4.0 → 6.5.0 transition, and the collaborator's follow-up confirms the same reporting gap on 6.7.0 → 6.8.0. The expected result is a successful package/version update accompanied by a separate, accurate optional-provider state and an actionable repair path. Enabling lifecycle scripts throughout the dependency tree is unnecessary for that result.

For example, after installing this branch's tarball into an isolated npm prefix with lifecycle scripts disabled, the public CLI returned the following result. Paths and the binding-search list are shortened:

{
  "status": "current",
  "currentVersion": "6.8.0",
  "latestVersion": "6.8.0",
  "installMethod": "npm",
  "optionalProviderReadiness": [{
    "provider": "frida",
    "scope": "native-module",
    "status": "unavailable",
    "reason": "module-load-failed",
    "detail": "Error: Could not locate the bindings file. Tried: ...",
    "remediation": "Frida could not load. Run the recovery command in its working directory to execute Frida's install script (it may download or build its native binding), then rerun rea update. Other dependency install scripts remain disabled during updates.",
    "recovery": {
      "command": ["npm", "--prefix", "<resolved-frida-root>", "run", "install", "--ignore-scripts=false"],
      "workingDirectory": "<installed-rea-root>"
    }
  }]
}

The command exited 0. Human-readable output exposed the same provider state, diagnostic and recovery arguments. The binding remained absent: checking readiness did not execute a repair.

Change and scope

The shared update workflow requests optional readiness only after a successful installation and exact version verification, or when the identified installation is already current. Unknown installation ownership leaves the field omitted. Existing unsuccessful update paths retain their original diagnostics and do not acquire a readiness result.

The Frida adapter owns module resolution, import diagnostics and recovery selection:

Resolve relative to the identified REA package, using a fresh Node subprocess so that an update cannot reuse the updater's cached Frida module. This also follows a dependency hoisted above the REA package.
Import the resolved entry and check the expected getDeviceManager export without invoking it. This establishes module-load readiness only; it does not enumerate devices, create a device manager, attach to a process or run instrumentation.
Return ready for a loadable module. An absent dependency and a module-load failure return distinct unavailable reasons. Launch, deadline, output-limit and uninterpretable-response failures remain unknown with probe-failed.
Preserve the original module error. Failed subprocesses retain bounded stdout/stderr and execution metadata; malformed replies also retain both diagnostic streams. An incomplete probe never becomes a claim that a native binding is missing.
Bound the check to a 10-second deadline and 64 KiB per captured stream, using the shared subprocess owner's stop and settlement behavior, including its 5-second termination grace.
Offer script recovery only when the resolved package manifest contains an install script. npm receives npm --prefix <resolved-frida-root> run install --ignore-scripts=false; Bun receives bun run --cwd <resolved-frida-root> install. Both are returned as argument arrays with a working directory and require explicit user execution.

File	Responsibility
`src/domain/OptionalProviderReadiness.ts`	Additive ready/unavailable/unknown result and optional recovery arguments.
`src/application/Update.ts`	Request readiness at the successful/current workflow boundary and return it independently of update success.
`src/application/UpdateRuntime.ts`	Supply installation ownership, package manager and the selected environment to the Frida adapter, removing package-runner identity.
`src/frida/FridaBindingReadiness.ts`	Resolve and import Frida in a bounded fresh process, interpret its reply, retain diagnostics and select scoped manual recovery.
`src/application/Update.test.ts`	Cover update/current propagation, successful exit classification, repair rechecking and ownership/verification boundaries.
`tests/boundary/process/fridaBindingReadiness.test.ts`	Exercise real subprocess loading, recovery, hoisting, CommonJS exports, diagnostic retention and stopped probes.
`tests/process-global/cliLogging.test.ts`	Keep the existing update-host fixture aligned with the required readiness effect.
`docs/installation.md`	Document the separate readiness contract and explicit recovery workflow.

The branch incorporates main at 8a657875079bc2644a1f6961447b730491e0d430. Its runtime composition keeps the current UpdateCommandRunner, and the manual recovery regression uses runInstall with awaited runner cleanup.

This is one update-reporting fix. Doctor inventory and the generic Frida-operation error message are separate concerns. There are no dependency, release-version, MCP catalog or generated metadata changes.

Contract and boundary impact

Semantic owner and earliest changed stage: the application update workflow owns whether readiness is requested and returned; the Frida adapter owns the provider-specific resolution and parsed load result. Existing CLI output serialization consumes the added field directly.
Contribution scope: an ordinary correctness/usability fix inside the existing update boundary. A new-provider or target-execution scope decision is not applicable.
CLI and MCP/tool-catalog contract: additive optionalProviderReadiness on successful identified update/current results. No MCP tool/schema changes. updated and current retain exit 0 for an unavailable or unknown optional module.
Provider/platform compatibility: the probe checks only module loading in the selected installation. Package-manager installation commands continue to disable dependency lifecycle scripts.
Evidence/provenance: the result retains the actual load diagnostic and scopes recovery to the resolved dependency, including a hoisted package. Unknown probe outcomes stay explicit.
Authority and cleanup: the added subprocess imports the installed dependency. It does not call the device manager or target APIs. The shared process primitive owns stop, captured output and settlement. Repair is advice, not an automatically executed action.
Package/generated impact: one runtime adapter and one domain result type are added; build outputs and native binaries are not committed.

Expected effects:

Read existing files or captured data.
Launch or attach to a process.
Inject instrumentation or run scripts/code.
Change process memory, registers, files, or configuration.
Contact network services.
Recover protected code or work around protections.
Documentation or usability only; no target interaction.
Not sure yet; investigation or maintainer guidance needed.

The added process/code effect is the dependency import. File/network effects include the existing package update; manual native-binding recovery can download or build only when the user invokes the returned command. No target attachment or instrumentation is added.

Evidence and regression coverage

The three readiness workflow regressions fail with the original Update.ts at base 1173c0a9dc1b352a60943a491462294db8f353ae because successful update/current results have no readiness field. They pass with this change. The complete update source suite passes 38 cases.

The new process-boundary suite passes 12 cases using actual child processes:

Loadable ESM and Frida's CommonJS named-export shape, with a device-manager function that throws if invoked.
A second probe observes a replaced module instead of cached state.
A module-load error is preserved; the scoped npm command explicitly runs a safe local fixture's install script, and another probe confirms readiness. The test checks that the repair marker did not exist before explicit execution.
Hoisted Frida resolution and Bun recovery arguments point to the actual package.
Missing optional package and missing install script produce useful states without an inappropriate recovery command.
A native loader that writes to stderr before throwing retains both its error and the bounded stderr diagnostic in the readiness result.
Process failure and contaminated probe output remain unknown.
Real deadline and stdout/stderr-limit cases preserve diagnostics, avoid offering recovery from incomplete observations and verify that the probe process has exited.

Installed-package verification also exercised the actual Frida 17.23.2 load failure rather than a fixture: this branch's tarball was installed into an isolated global prefix with --ignore-scripts; public human/JSON rea update output reported the missing binding with exit 0.

For the updated branch, the compiled production runUpdate and systemUpdateHost performed a real registry installation of 6.8.0 into that isolated prefix, verified the executable and returned updated plus Frida unavailable with exit 0. The starting version was supplied as 6.7.0 to the workflow; this is production-boundary verification, not a claim that the published 6.7.0 dispatcher already contains this fix.

Validation performed

Local validation used Windows x64, Node.js 24.22.1 and npm 11.16.0 for the top-level commands:

Current-tree typecheck, lint, formatting, module boundaries and metadata checks — passed within npm run check; npm run verify:architecture-guards also passed across 2,090 source files. The full static gate remains incomplete as described below.
npm run docs:check — passed, including 9 README consistency cases.
The update workflow, new Frida process boundary, CLI logging and CLI update-alias suites — 68 passed across 4 files.
The existing update-maintenance suite's other 27 cases passed, including the real noninteractive maintenance plan and subprocess/version-verification boundaries.
npm run verify:test-discovery — all 2,532 test files discovered exactly once after synchronization with main.
npm pack --dry-run --json, actual npm pack, isolated global tarball installation, public CLI human/JSON checks and the production update/install workflow — passed.
git diff --check — passed.

Full Linux/package coverage is delegated to CI. The current full static gate stops at one Knip unused-export report: GODOT_PCK_MAGIC in src/domain/godotPckFormat.ts. An independent checkout of main at 8a657875079bc2644a1f6961447b730491e0d430 reports the same unused export. That file and its consumers are unchanged by this PR. The baseline checkout also reports two unresolved worker imports because it has no compiled runtime artifacts; those import reports are absent from the built PR tree. A full npm run check pass is therefore not claimed.

The local verify:package run verified repository skill discovery and installation; its archive Python-source check requires python3, which is unavailable under that command on this Windows host. The unchanged Bun recorder cases are not claimed as locally passing; their Windows behavior was compared with the unmodified implementation base. Bun repair argument selection is covered, while execution of the actual Bun repair command remains unverified.

Real Frida native-ready device discovery or instrumentation is not established by these checks. The missing-binding case uses the real dependency; ready/repaired cases use controlled module fixtures. The Windows source-checkout addon was restored from the exact published 6.8.0 tarball and verified against its manifest/SHA-256, and is not committed.

Compatibility, safety, and release

No migration, configuration rewrite, package-manager upgrade or dependency change is required. Existing maintenance planning remains read-only and separate from readiness. Recovery targets the resolved optional dependency and stays opt-in. This change does not expose a new target operation or alter analysis evidence.

Author readiness

Human owner: @dakjdakd

I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
I declare this PR ready for initial maintainer review.

Before merge

This PR addresses a concrete problem or an agreed enhancement.
Material scope and authority questions are resolved for this routine update-reporting fix.
The PR has one focused outcome and the title follows type(scope): outcome.
Related issue is linked above.
Tests cover changed observable behavior and meaningful failure paths.
Owning documentation is updated; no generated contract changes are required.
Representative user-visible output is included above.
The final diff was checked for secrets, unrelated cleanup and unsupported claims.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/7216 **Author:** [@dakjdakd](https://github.com/dakjdakd) **Created:** 10/26/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/update-frida-readiness` --- ### 📝 Commits (2) - [`7ddb692`](https://github.com/morluto/rea/commit/7ddb692322f7f2309b0d2ba308a58bf0c94027b0) fix(update): report Frida readiness after verified updates - [`7577e30`](https://github.com/morluto/rea/commit/7577e30de587604250278bbb7f5a4abe215ccd2f) fix(update): retain Frida loader diagnostics and integrate main ### 📊 Changes **8 files changed** (+588 additions, -7 deletions) <details> <summary>View changed files</summary> 📝 `docs/installation.md` (+18 -7) 📝 `src/application/Update.test.ts` (+63 -0) 📝 `src/application/Update.ts` (+15 -0) 📝 `src/application/UpdateRuntime.ts` (+9 -0) ➕ `src/domain/OptionalProviderReadiness.ts` (+20 -0) ➕ `src/frida/FridaBindingReadiness.ts` (+153 -0) ➕ `tests/boundary/process/fridaBindingReadiness.test.ts` (+309 -0) 📝 `tests/process-global/cliLogging.test.ts` (+1 -0) </details> ### 📄 Description ## Summary Fixes #3556. `rea update` now reports whether the identified installation's Frida native module can load, separately from whether the CLI update succeeded. A missing or unloadable optional module keeps a verified update successful and returns its actual diagnostic together with a manual recovery command when the resolved Frida package provides an install script. Running the command again on an already-current installation checks readiness again without reinstalling. ## Problem and expected behavior The updater deliberately passes `--ignore-scripts` to npm and Bun. That preserves its existing lifecycle boundary, but Frida 17.23.2 obtains its native binding through an install script rather than shipping the binding in its package tarball. Verifying only the new CLI's version therefore allows a successful update to leave Frida unusable without explaining the problem until a later Frida operation. Issue #3556 establishes the published 6.4.0 → 6.5.0 transition, and the collaborator's follow-up confirms the same reporting gap on 6.7.0 → 6.8.0. The expected result is a successful package/version update accompanied by a separate, accurate optional-provider state and an actionable repair path. Enabling lifecycle scripts throughout the dependency tree is unnecessary for that result. For example, after installing this branch's tarball into an isolated npm prefix with lifecycle scripts disabled, the public CLI returned the following result. Paths and the binding-search list are shortened: ```json { "status": "current", "currentVersion": "6.8.0", "latestVersion": "6.8.0", "installMethod": "npm", "optionalProviderReadiness": [{ "provider": "frida", "scope": "native-module", "status": "unavailable", "reason": "module-load-failed", "detail": "Error: Could not locate the bindings file. Tried: ...", "remediation": "Frida could not load. Run the recovery command in its working directory to execute Frida's install script (it may download or build its native binding), then rerun rea update. Other dependency install scripts remain disabled during updates.", "recovery": { "command": ["npm", "--prefix", "<resolved-frida-root>", "run", "install", "--ignore-scripts=false"], "workingDirectory": "<installed-rea-root>" } }] } ``` The command exited 0. Human-readable output exposed the same provider state, diagnostic and recovery arguments. The binding remained absent: checking readiness did not execute a repair. ## Change and scope The shared update workflow requests optional readiness only after a successful installation and exact version verification, or when the identified installation is already current. Unknown installation ownership leaves the field omitted. Existing unsuccessful update paths retain their original diagnostics and do not acquire a readiness result. The Frida adapter owns module resolution, import diagnostics and recovery selection: - Resolve relative to the identified REA package, using a fresh Node subprocess so that an update cannot reuse the updater's cached Frida module. This also follows a dependency hoisted above the REA package. - Import the resolved entry and check the expected `getDeviceManager` export without invoking it. This establishes module-load readiness only; it does not enumerate devices, create a device manager, attach to a process or run instrumentation. - Return `ready` for a loadable module. An absent dependency and a module-load failure return distinct `unavailable` reasons. Launch, deadline, output-limit and uninterpretable-response failures remain `unknown` with `probe-failed`. - Preserve the original module error. Failed subprocesses retain bounded stdout/stderr and execution metadata; malformed replies also retain both diagnostic streams. An incomplete probe never becomes a claim that a native binding is missing. - Bound the check to a 10-second deadline and 64 KiB per captured stream, using the shared subprocess owner's stop and settlement behavior, including its 5-second termination grace. - Offer script recovery only when the resolved package manifest contains an install script. npm receives `npm --prefix <resolved-frida-root> run install --ignore-scripts=false`; Bun receives `bun run --cwd <resolved-frida-root> install`. Both are returned as argument arrays with a working directory and require explicit user execution. | File | Responsibility | | --- | --- | | `src/domain/OptionalProviderReadiness.ts` | Additive ready/unavailable/unknown result and optional recovery arguments. | | `src/application/Update.ts` | Request readiness at the successful/current workflow boundary and return it independently of update success. | | `src/application/UpdateRuntime.ts` | Supply installation ownership, package manager and the selected environment to the Frida adapter, removing package-runner identity. | | `src/frida/FridaBindingReadiness.ts` | Resolve and import Frida in a bounded fresh process, interpret its reply, retain diagnostics and select scoped manual recovery. | | `src/application/Update.test.ts` | Cover update/current propagation, successful exit classification, repair rechecking and ownership/verification boundaries. | | `tests/boundary/process/fridaBindingReadiness.test.ts` | Exercise real subprocess loading, recovery, hoisting, CommonJS exports, diagnostic retention and stopped probes. | | `tests/process-global/cliLogging.test.ts` | Keep the existing update-host fixture aligned with the required readiness effect. | | `docs/installation.md` | Document the separate readiness contract and explicit recovery workflow. | The branch incorporates main at `8a657875079bc2644a1f6961447b730491e0d430`. Its runtime composition keeps the current `UpdateCommandRunner`, and the manual recovery regression uses `runInstall` with awaited runner cleanup. This is one update-reporting fix. Doctor inventory and the generic Frida-operation error message are separate concerns. There are no dependency, release-version, MCP catalog or generated metadata changes. ## Contract and boundary impact - **Semantic owner and earliest changed stage:** the application update workflow owns whether readiness is requested and returned; the Frida adapter owns the provider-specific resolution and parsed load result. Existing CLI output serialization consumes the added field directly. - **Contribution scope:** an ordinary correctness/usability fix inside the existing update boundary. A new-provider or target-execution scope decision is not applicable. - **CLI and MCP/tool-catalog contract:** additive `optionalProviderReadiness` on successful identified update/current results. No MCP tool/schema changes. `updated` and `current` retain exit 0 for an unavailable or unknown optional module. - **Provider/platform compatibility:** the probe checks only module loading in the selected installation. Package-manager installation commands continue to disable dependency lifecycle scripts. - **Evidence/provenance:** the result retains the actual load diagnostic and scopes recovery to the resolved dependency, including a hoisted package. Unknown probe outcomes stay explicit. - **Authority and cleanup:** the added subprocess imports the installed dependency. It does not call the device manager or target APIs. The shared process primitive owns stop, captured output and settlement. Repair is advice, not an automatically executed action. - **Package/generated impact:** one runtime adapter and one domain result type are added; build outputs and native binaries are not committed. Expected effects: - [x] Read existing files or captured data. - [x] Launch or attach to a process. - [x] Inject instrumentation or run scripts/code. - [x] Change process memory, registers, files, or configuration. - [x] Contact network services. - [ ] Recover protected code or work around protections. - [ ] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. The added process/code effect is the dependency import. File/network effects include the existing package update; manual native-binding recovery can download or build only when the user invokes the returned command. No target attachment or instrumentation is added. ## Evidence and regression coverage The three readiness workflow regressions fail with the original `Update.ts` at base `1173c0a9dc1b352a60943a491462294db8f353ae` because successful update/current results have no readiness field. They pass with this change. The complete update source suite passes 38 cases. The new process-boundary suite passes 12 cases using actual child processes: - Loadable ESM and Frida's CommonJS named-export shape, with a device-manager function that throws if invoked. - A second probe observes a replaced module instead of cached state. - A module-load error is preserved; the scoped npm command explicitly runs a safe local fixture's install script, and another probe confirms readiness. The test checks that the repair marker did not exist before explicit execution. - Hoisted Frida resolution and Bun recovery arguments point to the actual package. - Missing optional package and missing install script produce useful states without an inappropriate recovery command. - A native loader that writes to stderr before throwing retains both its error and the bounded stderr diagnostic in the readiness result. - Process failure and contaminated probe output remain unknown. - Real deadline and stdout/stderr-limit cases preserve diagnostics, avoid offering recovery from incomplete observations and verify that the probe process has exited. Installed-package verification also exercised the actual Frida 17.23.2 load failure rather than a fixture: this branch's tarball was installed into an isolated global prefix with `--ignore-scripts`; public human/JSON `rea update` output reported the missing binding with exit 0. For the `updated` branch, the compiled production `runUpdate` and `systemUpdateHost` performed a real registry installation of 6.8.0 into that isolated prefix, verified the executable and returned `updated` plus Frida unavailable with exit 0. The starting version was supplied as 6.7.0 to the workflow; this is production-boundary verification, not a claim that the published 6.7.0 dispatcher already contains this fix. ## Validation performed Local validation used Windows x64, Node.js 24.22.1 and npm 11.16.0 for the top-level commands: - Current-tree typecheck, lint, formatting, module boundaries and metadata checks — passed within `npm run check`; `npm run verify:architecture-guards` also passed across 2,090 source files. The full static gate remains incomplete as described below. - `npm run docs:check` — passed, including 9 README consistency cases. - The update workflow, new Frida process boundary, CLI logging and CLI update-alias suites — 68 passed across 4 files. - The existing update-maintenance suite's other 27 cases passed, including the real noninteractive maintenance plan and subprocess/version-verification boundaries. - `npm run verify:test-discovery` — all 2,532 test files discovered exactly once after synchronization with main. - `npm pack --dry-run --json`, actual `npm pack`, isolated global tarball installation, public CLI human/JSON checks and the production update/install workflow — passed. - `git diff --check` — passed. Full Linux/package coverage is delegated to CI. The current full static gate stops at one Knip unused-export report: `GODOT_PCK_MAGIC` in `src/domain/godotPckFormat.ts`. An independent checkout of main at `8a657875079bc2644a1f6961447b730491e0d430` reports the same unused export. That file and its consumers are unchanged by this PR. The baseline checkout also reports two unresolved worker imports because it has no compiled runtime artifacts; those import reports are absent from the built PR tree. A full `npm run check` pass is therefore not claimed. The local `verify:package` run verified repository skill discovery and installation; its archive Python-source check requires `python3`, which is unavailable under that command on this Windows host. The unchanged Bun recorder cases are not claimed as locally passing; their Windows behavior was compared with the unmodified implementation base. Bun repair argument selection is covered, while execution of the actual Bun repair command remains unverified. Real Frida native-ready device discovery or instrumentation is not established by these checks. The missing-binding case uses the real dependency; ready/repaired cases use controlled module fixtures. The Windows source-checkout addon was restored from the exact published 6.8.0 tarball and verified against its manifest/SHA-256, and is not committed. ## Compatibility, safety, and release No migration, configuration rewrite, package-manager upgrade or dependency change is required. Existing maintenance planning remains read-only and separate from readiness. Recovery targets the resolved optional dependency and stays opt-in. This change does not expose a new target operation or alter analysis evidence. ## Author readiness Human owner: @dakjdakd - [ ] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [ ] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [ ] I declare this PR ready for initial maintainer review. ## Before merge - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] Material scope and authority questions are resolved for this routine update-reporting fix. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning documentation is updated; no generated contract changes are required. - [x] Representative user-visible output is included above. - [x] The final diff was checked for secrets, unrelated cleanup and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi added the

pull-request

label

2026-11-03 13:39:53 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#7722

No description provided.

Rows
Columns