This must be a bug with how data is cached in the store. When submissions have already been loaded in one survey, visiting the submissions list for another survey does not trigger submissions to be loaded anew, but just uses the same cached list.

Without having looked at this yet, I would recommend that whoever takes this on starts by looking at the structure of the survey store. Submissions should be stored per survey (e.g. submissionsBySurveyId). It makes no sense to have a single submissions list.

Continuing to focus on mopping up survey issues ahead of the big merge. Best to provide a nice clear landing zone for that thing. So I've been investigating your suggested fix here and there's even a // TODO: Segregate submission content from submission list just like your comment.

From there I've been looking at everything that either reads from or writes to submissionList. Each such place will need updating. Each one will now need a survey ID, and in some cases this will mean changing call signatures for store actions, hooks, and maybe components too. Nothing unusual here, just me mapping out the solution verbally.

I wanted to get a real clear understanding of the layout of these relationships before even beginning to code. So here's a flow diagram representing the network of relationships between everything connected to the submissionList property in the survey slice.

flowchart LR

  subgraph store
    subgraph state
      submissionList
    end

    subgraph actions
      submissionLoad
      submissionLoaded
      surveySubmissionUpdate
      surveySubmissionUpdated
      surveySubmissionsLoad
      surveySubmissionsLoaded
    end
  end

  submissionLoad --> submissionList
  submissionLoaded --> submissionList
  surveySubmissionUpdate --> submissionList
  surveySubmissionUpdated --> submissionList
  surveySubmissionsLoad --> submissionList
  surveySubmissionsLoaded --> submissionList

  subgraph hooks
    useHydratedSurveySubmission
    useSurveySubmission
    useSurveySubmissions
  end

  useHydratedSurveySubmission --> useSurveySubmission
  useSurveySubmission --> submissionList
  useSurveySubmission --> submissionLoad
  useSurveySubmission --> submissionLoaded
  useSurveySubmission --> surveySubmissionUpdate
  useSurveySubmission --> surveySubmissionUpdated
  useSurveySubmissions --> submissionList
  useSurveySubmissions --> surveySubmissionsLoad
  useSurveySubmissions --> surveySubmissionsLoaded

  subgraph components
    SurveyOptionColumnType
    SurveyResponseColumnType
    SurveySubmittedColumnType
    SurveySubmissionPane
    SurveySubmissionsList
  end

  subgraph pages
    submissions.tsx
  end

  submissions.tsx --> useSurveySubmissions
  SurveySubmissionsList --> useSurveySubmission
  SurveySubmissionPane --> useHydratedSurveySubmission

  submissions.tsx --> SurveySubmissionsList
  SurveyOptionColumnType --> SurveySubmissionPane
  SurveySubmissionsList --> SurveySubmissionPane
  SurveyResponseColumnType --> SurveySubmissionPane
  SurveySubmittedColumnType --> SurveySubmissionPane

I do see the hypothetical potential for an abstraction leak in SurveyOptionColumnType and friends. Those are loaded into ViewDataTable, which is used all over the place. If someone more familiar with this code can confirm that's not a risk here then the above flow chart is actually capturing the entire problem space in one neat little box.

Looks to me like this is a matter of grabbing surveyId out of useRouter().query and then passing it down through the params of the hooks and actions so that everywhere that needs it has it. Sound like a decent plan?