Time-profile mappings are reinserted into the params (under unknown circumstances)

[matt-dray]

Time-profile mappings were removed from the main inputs app in #655 and inputs selection app in #688 (including removal from default_params.json). This will be released as v5.2.

During pre-release QA for v5.2, @francisbarton found that, as expected, the time-profile mappings didn't show up in the 'view params' accordion of the run-model module.

However, after some clicking around, the time_profile_mappings dict was somehow reappearing and could be seen in the printed json in the 'view params' accordion:

  "time_profile_mappings": {
    "baseline_adjustment": "none",
    "activity_avoidance": {
      "ip": {},
      "op": {},
      "aae": {}
    },
    "efficiencies": {
      "ip": {},
      "op": {}
    },
    "expat": "linear",
    "repat_local": "linear",
    "repat_nonlocal": "linear",
    "non-demographic_adjustment": "none",
    "waiting_list_adjustment": "linear"
  },

(@francisbarton to confirm that it appeared exactly as above, i.e. it had all the keys of baseline_adjustment, activity_avoidance, etc, with the values they have above.)

This element was maintained in the params when returning to the same scenario with 'edit existing' from the inputs selection app.

I was unable to replicate.

How might this be possible given the removal of all time-profile code and references? The implication is that the inputs app is doing the insertion (rather than inputs app), given that a fresh scenario doesn't contain the time-profile mappings. Could this be linked somehow to caching?

[yiwen-h]

Was this a completely new scenario or editing / new from existing situation?

[matt-dray]

I believe @francisbarton happened upon it out of the blue, but found it again when starting new one from fresh. I also tried a new scenario, clicked and unclicked in every module, checked the params after each (de)selection and couldn't recreate. Haven't had time to look much more into it.

[francisbarton]

Just to confirm that I don't have a reproducible set of steps to trigger this behaviour. I was as Matt says just clicking around and suddenly somehow the time profiles bit reappeared.
I will try again to reproduce after a refresh of my browser cache, but that might be a case of trying to prove a negative (that is, if in fact clearing cache has solved the problem). It does seem likely it is a caching issue - though I had not previously used the inputs app for a long time so I'm sceptical that there would have been anything locally cached. But perhaps something in the Connect server cache???

[matt-dray]

@tomjemmett: any thoughts about this odd (potential) reappearance of time_profile_mappings? I appreciate it's hard to comment when we can't yet reproduce.

[francisbarton]

In my QA scenario 20260623-ndg2-fb-qa5 created on dev yesterday, the params ended up including:

"time_profile_mappings": {
    "baseline_adjustment": "none",
    "activity_avoidance": {
      "ip": {},
      "op": {},
      "aae": {}
    },
    "efficiencies": {
      "ip": {},
      "op": {}
    },
    "expat": "linear",
    "repat_local": "linear",
    "repat_nonlocal": "linear",
    "non-demographic_adjustment": "none",
    "waiting_list_adjustment": "linear"
  }

I confirm that these match what @matt-dray included in the initial issue description.

[tomjemmett]

is it because upgrade params doesn't happen on dev params?

[matt-dray]

Seemed to occur when Fran started a new scenario, which picked up the default_params.json that no longer contains time_profile_mappings. When looking under 'view params' the time profiles weren't there. It was only after some subsequent clicking inside the main app that they seemed to appear in 'view params'. Correct me if wrong, @francisbarton.

[francisbarton]

I think I've been ending up on the prod version of the inputs selection app.

To reproduce:

1. Go to https://connect.strategyunitwm.nhs.uk/
2. Search all Connect apps for "inputs"
3. Click on Inputs Selection App (dev)
4. In top bar, click on "Standalone" - for me this opens up in a new tab
5. This actually sends you to the non-current-dev version of the Inputs Selection app. (The default model version here is v5.1). Hence from this point aiming to edit an existing scenario (eg v5.1) but selecting the dev version instead is actually not removing the time profile mappings, because this is actually using a pre-v5.2 dev version of inputs.

Alternatively:

1. Go to https://connect.strategyunitwm.nhs.uk/
2. Search all Connect apps for "inputs"
3. Click on Inputs Selection App (dev)
4. Create a new scenario with model version 'dev'
5. Press start
6. Play with the params or whatever. time profile mappings do not show
7. To exit the app, click on the "< Content" link in the top left, left hand end of the top bar in Connect UI
8. Accidentally click on "NHP Inputs (dev)" instead of "NHP Inputs Selection app (dev)" (oops my bad, I know).
9. This redirects you to the ISA - but this is not the dev version (v5.1 is the default, and v5.2 is not shown in the model version dropdown). Seeing that you are in "NHP Inputs (dev)" might lead you to think that you are in the dev version of the ISA, however.
10. Now if you select model version = "dev" in advanced settings, and you don't notice that v5.2 is missing from the dropdown, and go ahead and create a new scenario you will get the time_profile_mappings even though you think you are in current dev.
11. But now if you go to the real dev ISA, and edit existing scenario, choose the scenario you created in step 10, and this time select "dev" in advanced settings, it does not get rid of the time profile mappings.
12. Similarly, if you now go to the real dev ISA, and "create new from existing", and choose the scenario you created in step 10, and select "dev" in advanced settings, it does not get rid of the time profile mappings.

[matt-dray]

Excellent sleuthing, well done. I can see how a prod/dev switcheroo would cause the issue to occur; ultimately a scenario with "app_version": "dev" will not go through the upgrade_params cascade and will not have time_profile_mappings stripped out.

I'm going to close the issue, but I'm also going to add a brief note in the wiki re QA and how Connect is set up (#692). It was good you uncovered this so that we can write better documentation (and/or reconsider the status quo), thank you.