Cabloy

Appearance

Generated Contract Consumption Debug Checklist ​

This page is a symptom-first diagnostic companion for one narrow frontend question:

when generated contract consumption still looks wrong, which frontend consumer layer should I inspect next?

Use this page together with:

TIP

Generated-contract diagnosis path

  1. Generated Contract Consumption Specimen — understand the family and choose the branch
  2. Generated Contract Consumption Verify Playbook — prove what should be true after a change
  3. Generated Contract Consumption Debug Checklist — use this page when the result is already wrong and you need the first failing layer

You are here: step 3. Previous recommended pages: Generated Contract Consumption Specimen and Generated Contract Consumption Verify Playbook.

Why this page exists ​

The current frontend generated-contract family already gives you:

  • a conceptual hub
  • list and entry branch pages
  • a proof-oriented verify playbook

What was still missing was one symptom-first page.

This page fills that gap.

It is not another generation page and not another branch specimen. It is the checklist for isolating the first failing consumer-side layer.

Shared symptom: contract surface missing or stale ​

Start here when the problem looks earlier than either list or entry runtime.

Primary anchors:

  • zova/src/suite/a-training/modules/training-student/src/apiSchema/trainingStudent.ts
  • optional direct schema consumer: zova/src/suite/a-home/modules/home-passport/src/model/passport.ts

What to inspect first:

  • does the expected generated schema surface exist at all?
  • do the expected API/schema methods still exist on the module-level schema bean?
  • if the issue is clearly that the generated contract itself never refreshed, stop and hand off to the bridge/regeneration docs instead of debugging consumer pages

Shared symptom: owner boundary wrong or stale ​

Start here when the contract surface looks present but consumption still feels wrong across both branches.

Primary anchor:

  • zova/src/suite/a-training/modules/training-student/src/model/student.ts

What to inspect:

  • does the thin semantic model still delegate to the stable resource owner?
  • did the module accidentally grow a competing second owner for the same contract slice?
  • do custom methods such as summary() or deleteForce() still point at the intended owner-backed consumer path?

If this layer is wrong, do not continue into list or entry runtime yet.

List branch symptoms ​

Only enter this branch when the issue is clearly list-page oriented.

Primary anchors:

  • zova/src/suite-vendor/a-cabloy/modules/rest-resource/src/page/resource/controller.tsx
  • zova/src/suite/cabloy-basic/modules/basic-page/src/component/blockPage/controller.tsx

Typical failures to classify:

A. List page renders blank or wrong blocks ​

Check:

  • whether the route shell resolves the expected resource
  • whether schemaRow?.rest?.blocks is actually present
  • whether the page is stopping before deeper runtime blocks can render

B. schemaRow, schemaFilter, or query state mismatch ​

Check:

  • whether the owner still exposes the expected schema surfaces
  • whether select(query) is still the active data path
  • whether basic-page:blockPage is still the deeper list runtime owner

C. List route shell looks right but visible behavior is still stale ​

At this point, you may need to hand off to:

Entry branch symptoms ​

Only enter this branch when the issue is clearly entry-page oriented.

Primary anchors:

  • zova/src/suite-vendor/a-cabloy/modules/rest-resource/src/page/entry/controller.tsx
  • zova/src/suite/cabloy-basic/modules/basic-pageentry/src/component/blockPageEntry/controller.tsx
  • zova/src/suite/cabloy-basic/modules/basic-pageentry/src/component/blockForm/controller.tsx
  • zova/src/suite/cabloy-basic/modules/basic-pageentry/src/component/blockToolbarRow/controller.tsx

Typical failures to classify:

A. Entry page shows missing data or missing form schema ​

Check:

  • whether resource, id, and formScene resolve correctly
  • whether owner-level formMeta, formSchema, and formData still load where expected
  • whether the shell is failing before deeper page-entry blocks can render

B. Wrong formScene or wrong toolbar visibility ​

Check:

  • whether the route shell derived the intended formScene
  • whether blockToolbarRow still consumes the expected host context
  • whether this is really a narrower action-visibility/form-scene issue rather than a full contract-consumption issue

C. Submit or page-meta behavior looks out of sync ​

Check:

  • whether blockForm still feeds submit/change callbacks back into the shared page-entry owner
  • whether the deeper entry runtime still owns page-meta updates rather than scattered local code

If this layer is still unclear, hand off to:

Classify the failure last ​

Only after the branch-local checks should you classify the problem as:

  • bridge/generation issue
  • deeper owner/runtime issue
  • list-branch issue
  • entry-branch issue

A practical rule is:

do not start from the deepest runtime layer until the shared contract surface and the stable owner boundary already look correct.

What this page does not re-explain ​

This page deliberately does not re-teach:

Its job is only to help you isolate the first failing frontend consumer layer.

Final takeaway ​

The cleanest way to debug generated-contract consumption is not to jump immediately into the deepest runtime files.

First isolate:

  • whether the generated contract surface itself is present
  • whether the stable owner boundary is still correct
  • whether the failure belongs to the list or entry branch

Only then descend into deeper internals if you still need them.

Released under the MIT License.

Copyright © 2016-present Cabloy