Skip to content

fix(sdk): fallback to get_project screenInstances when list_screens returns empty (#149) - #377

Open
davideast wants to merge 1 commit into
mainfrom
fix/issue-149-list-screens-fallback
Open

davideast wants to merge 1 commit into
mainfrom
fix/issue-149-list-screens-fallback

Conversation

@davideast

Copy link
Copy Markdown
Collaborator

Summary

Resolves #149 (Tier 2 — Part 1 of 3 in stack).

When a new project has screens generated via project.generate(), the Stitch backend populates get_project's screenInstances array (sourceScreen: "projects/{projectId}/screens/{screenId}") and returns the generated Screen objects in generate_screen_from_text, but the MCP list_screens endpoint returns [] until the project is manually opened in stitch.withgoogle.com.

Changes

  • EntityManager.prototype.getCachedScreensData(projectId): Returns raw screen payloads for any Screen instances already resolved in the current session for projectId.
  • StitchToolClient.prototype.callTool("list_screens", { projectId }):
    • When list_screens returns [], automatically falls back to get_project (screenInstances) and hydrates each sourceScreen via get_screen (falling back to ScreenInstance metadata if get_screen is unavailable), combined with any in-session cached screens in EntityManager.
    • When list_screens returns a subset of screens (stale index after an in-session project.generate()), merges any missing in-session generated screens from EntityManager.
  • Fixes both await project.screens() and await project.downloadAssets() immediately after project.generate().

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.

project.screens() returns empty after generate() until project is opened in web UI

1 participant