Skip to content

Handle failed group loads with shell groups and build issues - #46

Merged
AlexKempen merged 1 commit into
certfrom
claude/placeholder-groups-load-failure-4i71tq
Aug 30, 2026
Merged

Handle failed group loads with shell groups and build issues#46
AlexKempen merged 1 commit into
certfrom
claude/placeholder-groups-load-failure-4i71tq

Conversation

@AlexKempen

Copy link
Copy Markdown
Collaborator

Summary

This change improves handling of failed group loads by introducing "shell groups" - placeholder group records that persist even when their initial load fails. Failed groups are now flagged with a build issue so users understand why a group appears empty, and can retry or delete it.

Key Changes

  • Shell groups for failed loads: Groups are now created with a placeholder version ID before attempting to load, so failed loads leave behind a visible group record that can be retried or deleted
  • Build issue flagging: When a group load fails, a LOAD_FAILED build issue is recorded on the group, which displays to users instead of silently showing an empty group
  • Updated group contract: Added isLoaded boolean to GroupOut to distinguish between shell groups (never loaded) and fully loaded groups
  • Path handling for unloaded groups: Shell groups have a DocumentPath instead of InstancePath since they don't have a pinned version yet
  • UI improvements:
    • Group cards show disabled state for unloaded groups
    • Error message distinguishes between "group failed to load" vs "group has no visible elements"
    • Build status properly reports load failures even when a group has no insertables
  • Test coverage: Added tests for shell group behavior and updated seed utilities to support creating unloaded groups

Implementation Details

  • PLACEHOLDER_VERSION_ID constant extracted to schema for reuse across the codebase
  • createShellGroup now runs before attempting to load, ensuring the group persists even if load fails
  • flagFailedGroup function records the failure by adding a build issue to the group record
  • Later successful loads clear the build issue by recomputing from scratch
  • Frontend properly handles both DocumentPath and InstancePath for group paths

https://claude.ai/code/session_01Xda9Sd1YsAQZiEeQRN7hC7

An add whose load failed could leave nothing behind at all: the shell
group row was only written after `resolveGroupTarget` had fetched the
document and its latest version, so a version-less document (or any
Onshape hiccup in those two calls) produced an add that silently did
nothing. When the row did survive, nothing marked it as failed, and the
duplicate check on POST /group blocked re-adding the document either
way — leaving no way to tell whether the group was in the library.

Write the shell group first, using the name the route already fetched,
and record a LOAD_FAILED build issue on the group when a load throws, in
both the add and reload workflows. A later successful load recomputes
`buildIssues` and clears it.

Surface that state: `GroupOut.isLoaded` dims a never-loaded group's
title in the library list, and its page says it failed to load rather
than that it has no visible elements. A group with no pinned version now
links to the document instead of a `/v/placeholder` that 404s.
@AlexKempen
AlexKempen merged commit 946c50a into cert Aug 30, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants