feat(weave): frontend to allow deletion of single call #1664

gtarpenning · 2024-05-20T15:52:28Z

Single call deletion path. Also works for evaluations.

https://wandb.atlassian.net/browse/WB-18627

depends on:

circle-job-mirror · 2024-05-20T16:02:28Z

Preview this PR with FeatureBee: https://beta.wandb.ai/?betaVersion=be219d3b162238f9af8e4f8f4dc5712f4ebf4e2b

tssweeney · 2024-05-23T01:18:47Z

weave-js/src/components/PagePanelComponents/Home/Browse3/context.tsx

@@ -417,6 +417,7 @@ export const browse3ContextGen = (
        primaryDim
      )}&secondaryDim=${encodeURIComponent(secondaryDim)}`;
    },
+    refetchCalls: () => {},


This does not belong in the Url context. I'll keep reading and suggest an alternative place

tssweeney · 2024-05-23T01:22:15Z

weave-js/src/components/PagePanelComponents/Home/Browse3/context.tsx

+      closePeek();
+    } else {
+      // Not peeking (fullscreen) so navigate to the parent page
+      const path = history.location.pathname.split('/');


i'm not quite sure what the intention is here

This is totally a hack, but when you are in fullscreen mode (which you can navigate to directly with a link) there is nothing to close once you have deleted the call you are looking at. So we have to navigate up the tree after deletion as the current page is no longer valid...

tssweeney · 2024-05-23T01:23:46Z

weave-js/src/components/PagePanelComponents/Home/Browse3/pages/wfReactInterface/context.tsx

@@ -51,6 +51,7 @@ const WFDataModelFromTraceServerCallsOnlyProvider: FC = ({children}) => {
    return {
      useCall: tsWFDataModelHooks.useCall,
      useCalls: tsWFDataModelHooks.useCalls,
+      useCallsDelete: tsWFDataModelHooks.useCallsDelete,


nit/question: useCallsDelete follows a slightly different pattern (it returns a function). I wonder if there is a naming convention that could imply this pattern difference?

tssweeney · 2024-05-23T01:34:37Z

...s/src/components/PagePanelComponents/Home/Browse3/pages/wfReactInterface/tsDataModelHooks.ts

  const getTsClient = useGetTraceServerClientContext();
  const loadingRef = useRef(false);
  const [callRes, setCallRes] =
    useState<traceServerClient.TraceCallsQueryRes | null>(null);
  const deepFilter = useDeepMemo(filter);
+
+  const [lastFetch, setLastFetch] = useState<number | null>(null);


this whole block might be cleaner if instead of relying on states to trigger hooks, we instead:

Create a callback called doFetch that does the fetch and updates the state

Call doFetch inside the current useEffect
(by this point it is a pure refactor)

refetch is then literally just the doFetch method (:

tssweeney · 2024-05-23T01:47:32Z

weave-js/src/components/PagePanelComponents/Home/Browse3/pages/CallsPage/CallsTable.tsx

@@ -191,6 +191,9 @@ export const CallsTable: FC<{

  // Fetch the calls
  const calls = useCallsForQuery(entity, project, effectiveFilter);
+  if (calls.refetch) {
+    baseContext.refetchCalls = calls.refetch;


This pattern would not be ideal in situations where there are 2 calls table on the screen at the same time (as there is when you open an eval). In general, it is not good practice to assign some state like this to a global symbol. Two comments:

If you wanted to do a pattern like this, you would want to have a react context provider somewhere above that allows children to "register" and "unregister" refetch triggers.

But even that is a little odd - and you might want to reach for a reducer pattern with listeners.

Still, all these options are a bit odd - you really want someway to "broadcast" changes.

Got to run to dinner. Will respond later

tssweeney · 2024-05-23T05:12:27Z

weave-js/src/components/PagePanelComponents/Home/Browse3/pages/CallsPage/CallsTable.tsx

@@ -191,6 +191,9 @@ export const CallsTable: FC<{

  // Fetch the calls
  const calls = useCallsForQuery(entity, project, effectiveFilter);
+  if (calls.refetch) {
+    baseContext.refetchCalls = calls.refetch;


This pattern would not be ideal in situations where there are 2 calls table on the screen at the same time (as there is when you open an eval). In general, it is not good practice to assign some state like this to a global symbol. Two comments:

If you wanted to do a pattern like this, you would want to have a react context provider somewhere above that allows children to "register" and "unregister" refetch triggers.

But even that is a little odd - and you might want to reach for a reducer pattern with listeners.

Still, all these options are a bit odd - you really want someway to "broadcast" changes.

Let's see... in the best case scenario, upon deletion, two events occur:

All components on the page which include the deleted element adjust

If the primary view is of the deleted element, we navigate away.

Furthermore, when we have renaming, we want similar behavior: all cases of the name change are reflected immediately.

I can think of 4 families of solutions:

Don't do anything and just let the next user-invoked navigation reflect the changes.

Hard refresh the whole page.

Broadcast change events to listening components to manually reflect the change.

Note: this is closest to your current implementation (where "reflect" is facilitated via a refresh)

Automatically update any query hooks with the updated information.

The challenge here is not to be overly aggressive causing full-page reloads. Might be widespread refectors

are there others?...

What i don't like about #3 is that we put the responsibility on every rendering component to "listen" listen for changes. This is a lot a coupling in the design.

#4 is probably the best option across the board if done correctly. How does this relate to polling?

I wonder if the same mechanism which is hypothetically triggered in a poll event should be triggered after a mutation event? Where such a mechanism is: "refresh all active queries, without re-triggering loading/empty states". Yeah, doing this correctly might require a more widespread refactor.

Ok, so options...:

(low-cost version of No more weave-internal #4) I wonder if a low-cost change to OptionalTraceServerClientContextProvider that allows mutation hooks to refresh the client would be jarring? Might be worth a try.

Do what you are doing now, but with a proper context

Somehow have the other call hooks react to the delete event

excellent comment, will work through these and have a soln by tue

github-actions · 2024-05-24T14:16:05Z

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

…hub.com:wandb/weave into griffin/deleted-at-frontend-no-bulk-clean

tssweeney · 2024-05-29T17:06:10Z

...s/src/components/PagePanelComponents/Home/Browse3/pages/wfReactInterface/tsDataModelHooks.ts

@@ -48,8 +48,19 @@ const projectIdFromParts = ({
  project: string;
 }) => `${entity}/${project}`;

+// Trace server client keys that are promises
+type TraceServerClientPromiseKeys = {


Oh god! 🥷

tssweeney

SHIP IT!

gtarpenning changed the title ~~feat(weave): frontend to allow deletion of calls~~ feat(weave): frontend to allow deletion of single call May 20, 2024

gtarpenning marked this pull request as ready for review May 21, 2024 17:05

gtarpenning requested a review from a team as a code owner May 21, 2024 17:05

gtarpenning force-pushed the griffin/deleted-at-frontend-no-bulk-clean branch from 4fc23d1 to f7faab2 Compare May 22, 2024 20:35

gtarpenning requested review from jamie-rasmussen and tssweeney May 22, 2024 20:35

tssweeney reviewed May 23, 2024

View reviewed changes

gtarpenning force-pushed the griffin/deleted-at-frontend-no-bulk-clean branch 2 times, most recently from 6c23b18 to 99bbd22 Compare May 23, 2024 18:01

git pls

95bb392

gtarpenning force-pushed the griffin/deleted-at-frontend-no-bulk-clean branch from 8c088a6 to 95bb392 Compare May 24, 2024 14:19

gtarpenning added 6 commits May 24, 2024 10:21

Merge HEAD, branch 'griffin/deleted-at-frontend-no-bulk-clean' of git…

3610ee2

…hub.com:wandb/weave into griffin/deleted-at-frontend-no-bulk-clean

listeners and callbacks

a8836d5

remove refetch

c6f526a

lint

04418cc

remove old

80180fa

crazy typing

e1c657a

gtarpenning requested a review from tssweeney May 29, 2024 16:50

tssweeney reviewed May 29, 2024

View reviewed changes

tssweeney approved these changes May 29, 2024

View reviewed changes

gtarpenning merged commit cd86221 into master May 29, 2024
24 checks passed

gtarpenning deleted the griffin/deleted-at-frontend-no-bulk-clean branch May 29, 2024 17:38

github-actions bot locked and limited conversation to collaborators May 29, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(weave): frontend to allow deletion of single call #1664

feat(weave): frontend to allow deletion of single call #1664

gtarpenning commented May 20, 2024 •

edited

Loading

circle-job-mirror bot commented May 20, 2024 •

edited

Loading

tssweeney May 23, 2024

tssweeney May 23, 2024

gtarpenning May 23, 2024

tssweeney May 23, 2024

tssweeney May 23, 2024

tssweeney May 23, 2024

tssweeney May 23, 2024

gtarpenning May 23, 2024 •

edited

Loading

github-actions bot commented May 24, 2024 •

edited

Loading

tssweeney May 29, 2024

tssweeney left a comment

feat(weave): frontend to allow deletion of single call #1664

feat(weave): frontend to allow deletion of single call #1664

Conversation

gtarpenning commented May 20, 2024 • edited Loading

circle-job-mirror bot commented May 20, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gtarpenning May 23, 2024 • edited Loading

Choose a reason for hiding this comment

github-actions bot commented May 24, 2024 • edited Loading

Choose a reason for hiding this comment

tssweeney left a comment

Choose a reason for hiding this comment

gtarpenning commented May 20, 2024 •

edited

Loading

circle-job-mirror bot commented May 20, 2024 •

edited

Loading

gtarpenning May 23, 2024 •

edited

Loading

github-actions bot commented May 24, 2024 •

edited

Loading