iflytek/astron-agent · error · Error

useTableAddContext must be used within TableAddProvider

Error message

useTableAddContext must be used within TableAddProvider

What it means

`useTableAddContext` backs the 'add table' flow in database-detail with TableAddProvider, exposing state, actions, baseForm and databaseRef. When consumed outside the provider the null context throws 'useTableAddContext must be used within TableAddProvider'. Related convenience hooks (useTableAddState etc.) inherit the same requirement.

Solutions

Wrap the table-add component tree with <TableAddProvider> at the flow entry point.
If the component is reused, lift the provider to the common parent (e.g. the modal container).
Wrap test renders with TableAddProvider.
Use the convenience hooks (useTableAddState) instead of raw context to keep one guard location.

Example fix

// before
<TableAddSteps /> // throws

// after
<TableAddProvider>
  <TableAddSteps />
</TableAddProvider>

Defensive patterns

Strategy: try-catch

Validate before calling

const useTableAddContextSafe = (): TableAddContextType | undefined => useContext(TableAddContext);

Type guard

function hasTableAddContext(c: unknown): c is TableAddContextType {
  return !!c && 'baseForm' in (c as object) && 'actions' in (c as object);
}

Try / catch

let ctx: TableAddContextType;
try {
  ctx = useTableAddContext();
} catch {
  return <TableAddUnavailable />;
}

Prevention

Place <TableAddProvider> at the entry of the add-table flow (modal or route).
Reuse the convenience hooks (useTableAddState) so the guard stays centralized.
Include TableAddProvider in the shared test providers wrapper.
Never mount table-add subcomponents in pages outside the flow.

When it happens

Trigger: Rendering the table-add form/steps outside <TableAddProvider>; mounting the add-table component on another page; rendering it in a dialog whose content is created outside the provider; test/storybook renders without the wrapper.

Common situations: Reusing the add-table wizard in a different modal flow; refactoring the provider out of the mount point; conditional rendering that skips the provider on some branch.

Understand the failure class

Background: "missing required argument" and "the following required arguments were not provided": what required-argument errors mean and how to fix them — this error's family across 20 libraries.

Related errors

AI-assisted analysis of iflytek/astron-agent@5e758547a8 (2026-09-12). Data as JSON: /api/errors/9f9d20c14801ce0c. Report an issue: GitHub.

Appendix: source

Thrown at console/frontend/src/pages/resource-management/database-detail/database-table-add/context/table-add-context.tsx:203

      baseForm,
      databaseRef,
      actions,
    }),
    [state, dispatch, baseForm, databaseRef, actions]
  );

  return (
    <TableAddContext.Provider value={value}>
      {children}
    </TableAddContext.Provider>
  );
};

// Hook to use the context
export const useTableAddContext = (): TableAddContextType => {
  const context = useContext(TableAddContext);
  if (!context) {
    throw new Error('useTableAddContext must be used within TableAddProvider');
  }
  return context;
};

// 便捷hooks
export const useTableAddState = (): TableAddState => {
  const { state } = useTableAddContext();
  return state;
};

export const useTableAddActions = (): TableAddContextType['actions'] => {
  const { actions } = useTableAddContext();
  return actions;
};

export const useTableAddForm = (): FormInstance<BaseFormValues> => {
  const { baseForm } = useTableAddContext();
  return baseForm;

View on GitHub (pinned to 5e758547a8)