Skip to content

[decision] Every third-party host still has the upload defect objectui#10131 repaired — neither DefaultAppContent nor ConnectedShell mounts an UploadProvider, and useUpload fails OPEN to a local object URL #10168

Closed as not planned
Closed as not planned
[decision] Every third-party host still has the upload defect objectui#10131 repaired — neither DefaultAppContent nor ConnectedShell mounts an UploadProvider, and useUpload fails OPEN to a local object URL#10168
Labels
bugSomething isn't workingdomain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatpriority:p2

Description

@os-tesla
os-tesla
opened on Sep 20, 2026

Filed by the domain:ui execution seat (Seat: domain:ui#2, session session_018HrVaotisyhgmot9o2MLRq) while accepting PR objectui#10165 for objectui#10131. ⛔ Filed bare: domain:*, priority:* and type are triage's production. ⚠️ Cited by content, not by line address (AGENTS.md #11).

The finding — ⭐ this is the SCOPE LIMIT of a fix that just landed, stated so nobody assumes it is closed

PR objectui#10165 repaired a real defect: the console's UploadProvider was mounted inside a route element, while the action-param dialog and the modal form a modal action opens are rendered as siblings of that route element. Those dialogs therefore sat outside the provider, useUpload() failed open to a local object-URL adapter, and the file control reported a successful upload while no request ever left the browser.

⛔ That fix moved one mount point in apps/console and reaches nothing else. AppContent's own docstring points third-party hosts at DefaultAppContent, and ⛔ neither DefaultAppContent nor ConnectedShell mounts an UploadProvider — so every third-party host still has the defect, in the same dialogs, with the same silent object-URL fallback.

⚠️ Why this is a contract question, ⛔ not a repair

Whether @object-ui/app-shell should carry a default upload destination is a design decision about a published package's responsibilities, ⛔ not a bug to patch. Copying the console's mount into the shell would make the shell opinionated about where files go; leaving it means every host must know to mount a provider that nothing tells them about.

⭐ And the reason the whole family is silent is one line of already-published behaviour: useUpload falls back to createObjectUrlAdapter() when no provider is present — so a deployment with no upload destination configured at all is reported to the widget as a successful upload. Making that observable is a contract change to a published hook with live callers, so it belongs to that contract's owner. ⛔ This card does not decide it; it is the card that has to answer it, because the third-party-host question cannot be settled without saying what a host with no destination should see.

⚠️ Read PR objectui#10165's landed diff and its acceptance before deciding anything here — the altitude bug it fixed is the concrete instance of the abstract question this card asks.

Dedupe words

DefaultAppContent UploadProvider third-party host · ConnectedShell upload destination · useUpload fail-open object URL adapter · app-shell default upload destination contract · objectui#10131 scope limit

Generated by Claude Code

Activity

  1. objectstack-fleet commented on Sep 24, 2026

    @objectstack-fleet
    objectstack-fleetbot
    on Sep 24, 2026
    Contributor

    分诊首次定级:priority:p2 · bug · domain:ui · needs-user-decision —— 第三方宿主里上传文件会"假成功";怎么修是已发布包的契约问题,进维护者决策箱

    Path: packages/providers/src/UploadProvider.tsx(useUpload 的无 provider 回退 createObjectUrlAdapter)+ packages/app-shell 的 DefaultAppContent / ConnectedShell(均不挂 UploadProvider)

    Triage: lands in @object-ui/providers + @object-ui/app-shell ⇒ domain:ui, bug, priority:p2, needs-user-decision; rationale: measured — outside the console no shell mounts an UploadProvider, and useUpload then falls back to a tab-lifetime blob: URL that the widget reports as a successful upload, so a third-party host's file is "saved" as a link that dies with the tab; the repair changes the documented behaviour of a published hook and what app-shell is responsible for, which is a contract choice, not an execution detail.

    分诊席(session_01Tw7jnJinGHvoGSi8aFkhPJ,objectstack 座位贴 #6015),2026-09-24T16:02Z。⛔ 不认领、不派发。本席读完了卡面(本卡尚无评论),并在 objectui main(06b82b8)上核对。

    本席实测

    • useUpload():没有 provider 时返回 createObjectUrlAdapter() 的上传函数;该文件头注释写明这是有意保留的"legacy blob: URL 行为,让字段控件在没有 provider 时也能用"。
    • app-shell 导出的 DefaultAppContent(即 AppContent)与 ConnectedShell 都不挂 UploadProvider;控制台自己在 apps/console/src/App.tsx 的路由外层挂了一个(PR fix(console): mint a sys_file id for files picked in the global action dialogs #10165 把它挪到了正确的位置)。
    • ⭐ app-shell 自己已经在用 ObjectStack 的上传目的地:RecordAttachmentsPanel 直接构造 createObjectStackUploadAdapter。⇒ 这个壳并非对"文件存哪"毫无立场。
    • objectui ADR-0059 第 4 条:「UploadProvider … come from the host view」—— 规定由宿主提供,但没有规定宿主没提供时应当怎样。

    维护者速读

    第三方用 @object-ui/app-shell 搭自己的页面时,动作参数对话框和弹窗表单里的文件上传会显示"上传成功",但文件其实没有离开浏览器,存下的是一个关掉标签页就失效的临时链接。控制台已修,第三方宿主没修。要决定的是:没配置上传目的地时,平台该怎么做。

    • A:只改回退 —— 没有 provider 时上传直接报错("未配置上传目的地"),宿主必须自己挂。代价:所有依赖旧回退的宿主、示例和测试都要显式挂 provider。
    • B:只改壳 —— DefaultAppContent / ConnectedShell 默认挂 ObjectStack 上传适配器(可覆盖)。代价:用了壳的宿主修好了,绕开壳直接用字段控件的宿主仍然假成功。
    • C(推荐):A + B —— 壳默认挂 ObjectStack 适配器、宿主可覆盖;壳之外没有 provider 时报错;createObjectUrlAdapter 保留为显式选项(示例、测试)。

    请裁一个字母:A / B / C。

    os-decision-facets

    Prior rulings read: UploadProvider,upload destination,useUpload,createObjectUrlAdapter → objectstack 0 hits; objectui ADR-0059 §4 (the host supplies UploadProvider; silent on the no-provider case)

    推荐:C。 置信缺口:⛔ 不知道外部有多少宿主依赖 blob 回退;⛔ 本席没有在浏览器里复现第三方宿主的路径(读数来自源码和 PR #10165 的已验收结论)。

    Generated by Claude Code

  2. objectstack-fleet
    added
    bugSomething isn't working
    domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seat
    needs-user-decision
    priority:p2
    on Sep 24, 2026

  3. objectstack-fleet commented on Sep 24, 2026

    @objectstack-fleet
    objectstack-fleetbot
    on Sep 24, 2026
    Contributor

    分诊:关闭(not planned)—— 维护者:第三方用 app-shell 外壳搭页面的场景「暂时不考虑」

    分诊席(session_01Tw7jnJinGHvoGSi8aFkhPJ,objectstack 座位贴 #6015),2026-09-24T17:08Z。本卡在首次定级时被放进维护者决策箱(A 只改回退 / B 只改壳 / C 两者都做)。维护者答:「10168 第三方用我们的外壳(app-shell)搭页面时,暂时不考虑这个需求。」

    为什么是关闭而不是挂起

    • 维护者的答复是"这个场景暂不考虑",不是在 A/B/C 之间选一个。⇒ 三个选项都不执行。
    • 状态规则:pm:on-hold 只在有可自动检测的重启条件时才合法;"有第三方宿主要用"是一个业务事件,⛔ 没有任何机制能唤醒它 ⇒ 按规则关 not_planned,重开不花成本。
    • 控制台本身不受影响:它自己的 UploadProvider 已由 PR fix(console): mint a sys_file id for files picked in the global action dialogs #10165 挂在正确位置。

    本卡测得、关闭后仍然成立的事实(留给重开的人)

    • useUpload() 没有 provider 时回退到 createObjectUrlAdapter(),上传被报告为成功,存下的是关掉标签页就失效的 blob: 链接。
    • DefaultAppContent(即 AppContent)与 ConnectedShell 都不挂 UploadProvider;app-shell 自己的 RecordAttachmentsPanel 已经在用 createObjectStackUploadAdapter。
    • objectui ADR-0059 第 4 条规定由宿主提供 UploadProvider,但没有规定宿主没提供时怎么办。

    什么情况下重开

    有真实的第三方宿主(不是 objectui 控制台)用 @object-ui/app-shell 搭页面并需要上传文件;或者有用户报告"上传显示成功、刷新后文件没了"。重开时直接拿本卡的 A/B/C 给维护者裁。

    Generated by Claude Code

  4. objectstack-fleet
    removed
    needs-user-decision
    on Sep 24, 2026
  5. objectstack-fleet
    closed this as not plannedon Sep 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingdomain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatpriority:p2

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions