Fix GetInstances async postprocess

Altinn / app-localtest

Solution for testing apps locally on your own machine

8 stars 13 forks source link

Fix GetInstances async postprocess #110

Closed henrili closed 3 months ago

henrili commented 3 months ago

Make InstanceRepository.GetInstancesFromQuery async and await postProcess function call.

When getting a list of instances of an app, there is an async call to PostProcess, that fills in data-array (among other tings). The GetInstances method did not await this postProcess.

Description

The whole function is made async. The ForEach call is replaced with Select, and wrapped in Task.WhenAll( ). The Task wrapper on the returned object is removed.

Related Issue(s)

None. Issue was discussed on Slack channel produkt-altinn-studio

Verification

[X] Your code builds clean without any errors or warnings
[X] Manual testing done (required)
[ ] Relevant automated test added (if you find this hard, leave it and we'll help out)
[ ] All tests run green

Documentation

[ ] User documentation is updated with a separate linked PR in altinn-studio-docs. (if applicable)

henrili commented 3 months ago

woops. I added one more fix, that I intended to create a separate PR for, but it got included in this PR.

Short description

The GetInstancesFromQuery method loads all instances from disk, and removes any that do not match given filters. The logic for the filter "process.currentTask" was missing. The last commit adds missing logic.

ivarne commented 3 months ago

woops. I added one more fix, that I intended to create a separate PR for, but it got included in this PR.

Both are small and in the same file, so I think 1 PR is sufficient (even though the issues are different).

I wish we one day will be able to get rid of this mock implementation of storage and rather provide more advanced users with a simple way to run the production version with a real database locally.

henrili commented 3 months ago

I wish we one day will be able to get rid of this mock implementation of storage and rather provide more advanced users with a simple way to run the production version with a real database locally.

I think there's pros and cons. Its definitly preferable to have the most production-like dev environment, but I like the fact that i can easily browse the data as files for my debugging purposes. I can even do simple edits in the files to simulate special conditions, but that become a few steps more difficult in a DB.

That being said. I do run the DB for our own backend within docker for development environments.

ivarne commented 3 months ago

I think there's pros and cons.

Yes, I like the simplicity of a file based storage as well. It's just that it is way too easy for them to get out of sync, so that your local testing does not model the behaviour in the production environment.