Projects containing file-input blocks cannot be exported to .deepnote, so workspace-wide checks never see them · Issue #570 · deepnote/deepnote · GitHub
Skip to content

Projects containing file-input blocks cannot be exported to .deepnote, so workspace-wide checks never see them #570

Closed as not planned
Closed as not planned
Projects containing file-input blocks cannot be exported to .deepnote, so workspace-wide checks never see them#570

Description

@jamesbhobbs
jamesbhobbs
opened on Oct 8, 2026

What happens

Some projects cannot be exported to .deepnote because they contain block types that have no
document representation — file-input blocks are the case we hit. deepnote sync therefore
produces a workspace tree that is missing those projects entirely.

Why it matters beyond sync

Every workspace-wide check reads the synced tree, so a project that cannot be exported is not
"partially analyzed" — it is absent, and absent in a way nothing reports. That silently shrinks
the corpus for:

  • integration inventory and orphan detection (an integration used only by an unexportable project
    reads as an orphan)
  • egress and shared-credential detection (a credential in an unexportable project is invisible, so
    a genuinely shared one can read as single-project)
  • subject scatter and the DSAR index (a person's data in an unexportable project will not be found
    by deepnote subjects lookup, which is the case where a wrong answer is most expensive)
  • consensus checks, which are already sensitive to how much of the workspace they can see

The governance work in #555–#560 depends on the synced tree being the whole workspace. It is not
blocked on this — the checks are useful on the projects they can see — but the gap belongs on the
record, because "no findings" and "no data" look identical in the output today.

Suggested direction

Two separable pieces:

  1. Decide what the .deepnote format should do with a block type that has no document form —
    round-trip it opaquely, or export a placeholder that marks the project as lossy.
  2. Until then, have deepnote sync report the projects it could not export, so a workspace-wide
    check can say how much of the workspace it actually read.

(2) alone would be enough to stop the silence, and is much the smaller change.

Activity

  1. linear-code commented on Oct 8, 2026

    @linear-code
    linear-codeBot
    on Oct 8, 2026 – with Linear Code

    GRN-5745

  2. jamesbhobbs commented on Oct 8, 2026

    @jamesbhobbs
    jamesbhobbs
    on Oct 8, 2026
    ContributorAuthor

    Closing: I filed this without verifying it, and it is wrong

    I checked the claim against main (aa891df) and it does not hold. input-file blocks have a full document representation in the .deepnote format:

    • inputFileBlockSchema is defined at packages/blocks/src/deepnote-file/deepnote-file-schema.ts:393 and is a member of the deepnoteBlockSchema discriminated union, alongside the other seven input types.
    • A project containing one parses, serializes and re-parses cleanly, keeping deepnote_allowed_file_extensions and the variable name.
    • deepnote lint analyses it normally — it raises missing-input and unused-variable against the block like any other input.
    • deepnote convert -f jupyter represents it too, emitting upload = None.

    So there is no block type here with no document representation, and nothing is excluded from the synced tree for that reason. I filed this from a description I was given rather than from the code, which was a mistake — the premise should have been the first thing I checked, not the last.

    If the real limitation is on the Deepnote Cloud export side rather than in this repository, that belongs in an issue written by someone who can see that code; I have no evidence for it from here and would only be guessing again.

    The companion issue #571 did turn out to describe something real, though not for the reason either of us thought — I have rewritten it there.

  3. jamesbhobbs
    closed this as not plannedon Oct 8, 2026

  4. dinohamzic commented on Oct 8, 2026

    @dinohamzic
    dinohamzic
    on Oct 8, 2026
    Contributor

    The project failed to export because of bad data in one block. File input blocks themselves export fine.

    Why the first read was wrong

    • The .deepnote format supports input-file blocks.
    • The export failed because of one block's data. Its deepnote_allowed_file_extensions setting was stored as null, but the format only allows text there, so the block failed validation.
    • The error message only named the block type: "cannot be represented in a .deepnote document: input-file". That made it look like no file input block could be exported. The server didn't log the actual validation error either, so the real cause was hidden.
    • One bad block fails the whole project, which is why every notebook in it was missing from the sync.
    • The app doesn't write null there today, so this is old data.

    Solution

    • The affected block is fixed, and the project now exports. It will show up in the next sync.
    • A server-side fix is in review:
      • The export treats a stored null in that field as missing, so this case can't break an export again.
      • When a block can't be exported, the error now names the block, its id, and the field that failed.
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

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions