Results step never shows any output: the Fetch results button is not wired, and the publish route returns 500

[mosoriob]

What happens

A run completes on Tapis and writes its outputs, but the Results step shows
— No results available — for ever. The Fetch results button does nothing.

Measured at TACC on 2026-08-09 while resolving #92. Thread jx8ibyilmsmg1pvt, model
SUBSIDE Allocation Specification. Two runs went to Tapis: one succeeded, one failed on bad
input data. The successful job wrote a full output set to its archive:

✓ All processing complete!
Output directory: /scratch/.../d0b7b4c0-...-007/output/

execution_result in Hasura holds 0 rows for both executions.

Two independent causes

1. ui-react never asks. MintResults guards on an optional prop that no parent passes:

// MintResults.tsx:122
if (!onPublishResults) return;

MintThread.tsx:349 renders <MintResults> with threadData, executions, canWrite,
ingestionApiAvailable, onContinue and onFetchRuns — and no onPublishResults. So
handlePublish returns on its first line. The click makes no network request at all.

2. The server route it should call also fails. Called by hand with the same bearer token
the app holds:

Call	Result
POST .../subtasks/{id}/outputs	400 No executions found to publish
POST .../executions/{success-id}/outputs	500 Request failed with status code 403
POST .../executions/{failed-id}/outputs	400 Execution is not successful — correct

registerOutputs reaches Tapis Files or CKAN and gets a 403, which surfaces as a 500. The
subtask-level route catches every per-execution error and reports the same
No executions found to publish regardless, so the 403 is invisible from the API. Same opacity
class as #108.

Why it matters

Fixing only cause 1 is not enough — the button would then call a route that returns 500. Both
need a fix before a user can see a run's outputs.

Scope

Blocks #77. A user who runs a model cannot reach its results.

Cause 1 is ui-react. Cause 2 is mint-ensemble-manager, and the 403 needs a look at which
credential registerExecutionOutputs uses.

[mosoriob]

Status 2026-08-11: cause 2 is fixed and deployed. End-to-end proof waits on Lonestar6.

Cause 1 is confirmed fixed. The button now makes a request. It sent
POST /v1/problemStatements/swi983qfmsmbp8x6/tasks/1hdzfg5zmsmbp98f/subtasks/jx8ibyilmsmg1pvt/outputs
from the signed-in app at localhost:3000. Before #122 it made none.

Cause 2 was a dead CKAN token, and it is now replaced. Measured live:

token	organization_list_for_user	package_show results-from-dynamo
deployed (old)	[] — resolves to no user	403 Access denied: User not authorized
new	admin on 13 orgs, incl. dynamo	200, 34 resources

The new token also performed the exact write the route needs: resource_create on
results-from-dynamo returned 200, and the probe resource was deleted. The dataset is
unchanged at 34 resources.

The token is deployed. TACC runs helm upgrade mint . -f values.yaml -f secrets.yaml from
~/tacc-values/shared on login-shared, and secrets.yaml now holds it. The rendered
ConfigMap hashes to the new value.

The upgrade alone changed nothing, and that is a second finding. The pod stayed 95 days old
with 0 restarts. A config-only upgrade does not roll the Deployment, and config.json mounts
with subPath, which never receives ConfigMap updates. An explicit
kubectl rollout restart was required. Filed as #123.

A third cause, and it is not ours

With the new token live, the route still fails — earlier in the flow, before CKAN is reached:

NotFoundError: No files found for model https://w3id.org/okn/i/mint/da90f610-...

mintOutputs holds 1 output (Output Json). The Tapis file list is empty for all 15 candidate
folders. Probing Tapis directly with the same user token says why:

FILES_CLIENT_SSH_SESSION_POOL_ERROR ... Host: ls6.tacc.utexas.edu, Port: 22,
EffectiveUserId: mosorio, AuthnMethod: TMS_KEYS,
ConnectionGroupStatus: RECENT_CONNECTION_FAILURE

Lonestar6 is in maintenance. The job archive lives on it, at
/work/07025/mosorio/ls6/tapis-jobs-archive/2026-08-09Z/...-d0b7b4c0-...-007/output. Every path
on system ls6 answers 500, including /. This is an outage, not a defect, and it is unrelated
to the CKAN fix.

Retry after the maintenance ends. Same thread jx8ibyilmsmg1pvt, same button. That run is
what proves cause 2.

Two traps found while diagnosing this

Both are filed as #125.

• The folder loop discards the Tapis error and logs No files found for model in <folder> path
  15 times. An outage and an empty directory read the same.
• getLog silently returns the job history when the tapisjob.out download fails. It answered
  200 with plausible text while file access was broken, which first suggested Tapis was fine.

Nothing was written to CKAN today.