Skip to content

feat(frontend): choose between following and pinning in the share dialog - #8578

Draft
yangzhang75 wants to merge 3 commits into
apache:mainfrom
yangzhang75:pin/6-panel
Draft

yangzhang75 wants to merge 3 commits into
apache:mainfrom
yangzhang75:pin/6-panel

Conversation

@yangzhang75

@yangzhang75 yangzhang75 commented Sep 17, 2026 •

Copy link
Copy Markdown
Contributor

What changes were proposed in this PR?

Everything so far has been machinery with nothing to drive it. This is the control: in the share
dialog, a published workflow gets a two-way switch for what the public sees.

  • Two states, so the control is a switch. Follow latest is what Texera does today — the
    public sees the author's latest, updated on every save. Pinned holds the version they froze.
    Both choices stay on screen, so the author reads what the options are instead of inferring one
    from the label of the other.
  • Everything under the switch describes the side it is on — a fact, not a warning: keeping an
    older version public is a legitimate choice. Green while the public has everything, amber once a
    pin is holding a version back.
  • Only the pinned side has more to say. Behind, that is the one decision the state leaves
    open, so it gets a card: which version is out there, what it costs, and the act that ends it.
  • The panel describes the saved copy, and the editor saves on a debounce, so it re-reads when
    a save lands. Deliberately it does not force a save first: the canvas is not always the workflow
    — it is empty while one loads, and stays empty if the collaborative model never arrives — so a
    save nobody asked for could write that emptiness over every operator the workflow had.

Behind a flag, off. gui.workflow-workspace.version-pinning-enabled defaults to false, so
merging this changes nothing anyone can see: the dialog is exactly what it is today and does not
even ask the server about a state it cannot show. The last PR of the series turns it on, so the
feature appears only once every surface that has to agree with a pin is in place.

Any related issues, documentation, discussions?

Closes #7942
Part of #7828. Design discussion: #7128. Stacked on #8576 and #8577; until those merge this
PR shows their commits too, and the review here is the last one.

How was this PR tested?

Frontend: the share-access spec covers the panel end to end — each of the three states and the
sentence it shows, the switch calling pin and unpin and doing nothing when the side already in
force is picked, "Update to current" asking for a re-pin, the date the card names, failures
surfacing as a notification, the panel staying hidden for a workflow that is not published and
for a user who cannot publish, and the re-read when a save lands. One case covers the flag being
off: nothing renders and the status endpoint is not called. The persist spec covers the new
pin/unpin/status calls and that a save is announced when it lands rather than when it is sent.
Full suite passes (6602), production (AOT) build passes, prettier clean.

Backend: GuiConfigSpec pins the flag's default to off (72 tests); the dashboard package passes
(572); scalafmt clean.

Was this PR authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Opus 5)

🤖 Generated with Claude Code

@github-actions github-actions Bot added engine frontend Changes related to the frontend GUI common platform Non-amber Scala service paths labels Sep 17, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Automated Reviewer Suggestions

Based on the git blame history of the changed files, we recommend the following reviewers:

  • Contributors with relevant context: @aglinxinyuan, @tanishqgandhi1908, @mengw15
    You can notify them by mentioning @aglinxinyuan, @tanishqgandhi1908, @mengw15 in a comment.

@codecov-commenter

codecov-commenter commented Sep 17, 2026 •

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 97.54902% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.34%. Comparing base (3726dd7) to head (0332da9).
⚠️ Report is 29 commits behind head on main.

Files with missing lines Patch % Lines
...shboard/user/workflow/WorkflowPublishService.scala 94.87% 1 Missing and 1 partial ⚠️
...ra/web/resource/dashboard/SearchQueryBuilder.scala 50.00% 1 Missing ⚠️
...esource/dashboard/WorkflowSearchQueryBuilder.scala 97.95% 1 Missing ⚠️
...ponent/user/share-access/share-access.component.ts 97.72% 0 Missing and 1 partial ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##               main    #8578      +/-   ##
============================================
+ Coverage     92.33%   92.34%   +0.01%     
  Complexity     5045     5045              
============================================
  Files          1260     1260              
  Lines         54067    54240     +173     
  Branches       6755     6781      +26     
============================================
+ Hits          49921    50090     +169     
- Misses         2486     2489       +3     
- Partials       1660     1661       +1     
Flag Coverage Δ *Carryforward flag
access-control-service 77.38% <ø> (ø)
agent-service 99.16% <ø> (ø) Carriedforward from 3726dd7
amber 87.37% <96.80%> (+0.05%) ⬆️
computing-unit-managing-service 60.48% <ø> (ø)
config-service 87.50% <100.00%> (+0.12%) ⬆️
file-service 82.00% <ø> (ø)
frontend 96.55% <98.71%> (+<0.01%) ⬆️
notebook-migration-service 83.73% <ø> (ø)
pyamber 98.57% <ø> (ø) Carriedforward from 3726dd7
workflow-compiling-service 72.43% <ø> (ø)

*This pull request uses carry forward flags. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@github-actions

github-actions Bot commented Sep 17, 2026 •

Copy link
Copy Markdown
Contributor

⚠️ Benchmark changes need a look

🟢 4 better · 🔴 1 worse · ⚪ 10 noise (<±5%) · 0 without baseline

Compared against main 3726dd7 benchmarked on this same runner, so the delta is largely free of cross-runner hardware noise. The "7d avg" column still reflects the gh-pages dashboard. Treat <±5% as noise unless repeated.

Dashboard · Run

config throughput MB/s latency max Δ latest / 7d
🔴 bs=10 sw=10 sl=64 576 0.351 17,186/23,505/23,505 us 🟢 -20.0% / 🔴 +66.5%
🟢 bs=100 sw=10 sl=64 1,240 0.757 80,921/88,155/88,155 us 🟢 -12.7% / 🟢 -18.8%
⚪ bs=1000 sw=10 sl=64 1,395 0.851 711,619/806,852/806,852 us ⚪ within ±5% / 🟢 -12.3%
Baseline details

Latest main 3726dd7 from same runner

config metric PR latest main 7d avg Δ latest Δ 7d
bs=10 sw=10 sl=64 throughput 576 tuples/sec 595 tuples/sec 968.33 tuples/sec -3.2% -40.5%
bs=10 sw=10 sl=64 MB/s 0.351 MB/s 0.363 MB/s 0.591 MB/s -3.3% -40.6%
bs=10 sw=10 sl=64 p50 17,186 us 15,944 us 10,646 us +7.8% +61.4%
bs=10 sw=10 sl=64 p95 23,505 us 29,376 us 14,120 us -20.0% +66.5%
bs=10 sw=10 sl=64 p99 23,505 us 29,376 us 16,498 us -20.0% +42.5%
bs=100 sw=10 sl=64 throughput 1,240 tuples/sec 1,250 tuples/sec 1,252 tuples/sec -0.8% -1.0%
bs=100 sw=10 sl=64 MB/s 0.757 MB/s 0.763 MB/s 0.764 MB/s -0.8% -0.9%
bs=100 sw=10 sl=64 p50 80,921 us 79,363 us 83,736 us +2.0% -3.4%
bs=100 sw=10 sl=64 p95 88,155 us 100,957 us 92,464 us -12.7% -4.7%
bs=100 sw=10 sl=64 p99 88,155 us 100,957 us 108,561 us -12.7% -18.8%
bs=1000 sw=10 sl=64 throughput 1,395 tuples/sec 1,381 tuples/sec 1,321 tuples/sec +1.0% +5.6%
bs=1000 sw=10 sl=64 MB/s 0.851 MB/s 0.843 MB/s 0.806 MB/s +0.9% +5.6%
bs=1000 sw=10 sl=64 p50 711,619 us 722,244 us 811,260 us -1.5% -12.3%
bs=1000 sw=10 sl=64 p95 806,852 us 775,268 us 847,636 us +4.1% -4.8%
bs=1000 sw=10 sl=64 p99 806,852 us 775,268 us 879,277 us +4.1% -8.2%
Raw CSV
config_idx,batch_size,schema_width,string_len,num_batches,total_ms,total_tuples,total_bytes,tuples_per_sec,mb_per_sec,lat_p50_us,lat_p95_us,lat_p99_us
0,10,10,64,20,347.44,200,128000,576,0.351,17185.86,23505.16,23505.16
1,100,10,64,20,1612.35,2000,1280000,1240,0.757,80920.52,88154.98,88154.98
2,1000,10,64,20,14337.84,20000,12800000,1395,0.851,711619.35,806851.80,806851.80

@yangzhang75
yangzhang75 force-pushed the pin/6-panel branch 4 times, most recently from 831ab86 to d741134 Compare September 28, 2026 21:13
@yangzhang75
yangzhang75 marked this pull request as ready for review October 6, 2026 18:42
@yangzhang75
yangzhang75 marked this pull request as draft October 7, 2026 01:36
@yangzhang75
yangzhang75 force-pushed the pin/6-panel branch 3 times, most recently from 85222a2 to 624ffc5 Compare October 13, 2026 00:55
yangzhang75 and others added 3 commits October 18, 2026 15:06
Search and the listings it feeds were reading the author's live columns,
which for a pinned workflow is the one copy the public cannot open. A
draft would turn up in a public search under a title nobody has seen, and
the card would advertise a name the detail page does not show.

Each filter is now applied to whichever copy the caller may see:
`onVisibleCopy` builds the same filter twice -- over the live columns for
rows the caller was granted access to, over the frozen ones for rows they
reach only because the workflow is public -- and ORs the two. A
disjunction over bare columns rather than a CASE, so each side stays
eligible for its own fulltext index. Unpinned public rows fall back to
the live columns, so a following workflow searches exactly as it does now.

Listings carry two more things from the same query: the frozen name and
description to show a viewer without granted access, and whether the copy
on show is behind the author's working copy. `constructWhereClause` takes
`includePublic` for this; the other builders accept and ignore it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The author can pin a version, and their working copy then moves on. This
gives them a way back to what the public is seeing: pinning leaves an
anchor in the revision history they already use, and the panel marks it
as the one currently public, so restoring the published version is the
restore they already know.

The anchor is a version row whose delta is the identity patch, so
replaying it returns exactly what was pinned however many edits pile up
after. An existing row cannot stand in: a version row replays to the
content as it was *before* the change it records. Pinning content that is
already the pinned one reuses its anchor rather than adding a twin, and
the read that decides takes a row lock so two pins racing cannot both
insert.

Two consequences the anchor forces:

- It must not start the version panel's aggregation window. It lands
  seconds after the save it freezes, and the panel folds close-together
  versions into the newest, which would hide the author's own save behind
  a row they never made.
- The revision history is now readable only with granted access, or while
  nothing is pinned. Replaying a version folds deltas back from the
  author's current content, so listing versions of a pinned workflow would
  hand a public viewer the very edits the pin is holding back.

`publish-status` carries the pinned version's date, read from the version
row so the dialog and the panel print one value rather than two clocks'.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The share dialog said whether a workflow was public and nothing about
which copy the public was getting. With pinning that is now a choice, so
the dialog carries it: a two-option control -- Follow latest, or Pinned --
under the Public tile, plus a line naming the pinned version by the date
it went public.

Follow latest is the default and is exactly what publishing does today.
Pinning freezes the version the author has now; while a pin is in place
and their working copy has moved on, the panel says so and offers Update
to current, which is the only way those edits reach the public.

The panel re-reads its state when a save lands rather than on a timer:
`WorkflowPersistService` now emits on persist, rename and re-describe,
which is what makes "your edits are not public yet" appear as soon as the
autosave lands rather than the next time the dialog is opened. Publishing
returns the state it produced, so the panel does not have to ask again.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

common engine frontend Changes related to the frontend GUI platform Non-amber Scala service paths

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Frontend: choose between following and pinning in the share dialog

2 participants