-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EES-5238 - adding new HTTP trigger and orchestration for completing the next data set version import #5038
EES-5238 - adding new HTTP trigger and orchestration for completing the next data set version import #5038
Conversation
46d6687
to
1379b40
Compare
1379b40
to
1b304fe
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering if a name of CompleteNextDataSetVersionImportRequest
might be more accurate? I know it's more verbose but this request is specific to this trigger I think? So might be useful to make it very explicit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had originally planned for it to be reusable for any orchestrations that simply require a DataSetVersionId to operate, but since this is the only one so far, I'm happy to rename it.
In keeping with the existing naming convention, I've gone with NextDataSetVersionCompleteRequest
alongside its counterpart NextDataSetVersionCreateMappingsRequest
, which I've renamed from NextDataSetVersionCreateRequest
.
if (nextVersion is null) | ||
{ | ||
return CreateDataSetVersionIdError( | ||
message: ValidationMessages.DataSetVersionNotFound, | ||
dataSetVersionId: request.DataSetVersionId); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a 404
might be more appropriate here? But I guess our 400s are more descriptive than our empty 404s. But I reckon I'd have 404'd it if I'd have written it myself. But I can be swayed either way on this one!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a new ValidationUtils.NotFoundResult() method and equivalent assertion ActionResultTestExtensions.AssertNotFoundWithValidationProblem() method for testing the generated errors.
.Validate(request, cancellationToken) | ||
.OnSuccess(_ => GetNextDataSetVersionInMappingStatus(request, cancellationToken)) | ||
.OnSuccessDo(_ => GetCompletedDataSetVersionMapping(request, cancellationToken)) | ||
.OnSuccessCombineWith(nextDataSetVersion => | ||
GetImportInManualMappingStage(request, nextDataSetVersion)) | ||
.OnSuccess(async versionAndImport => | ||
{ | ||
var (nextVersion, importToContinue) = versionAndImport; | ||
|
||
importToContinue.InstanceId = Guid.NewGuid(); | ||
publicDataDbContext.DataSetVersionImports.Update(importToContinue); | ||
await publicDataDbContext.SaveChangesAsync(cancellationToken); | ||
|
||
await ProcessCompletionOfNextDataSetVersionImport( | ||
client, | ||
dataSetVersionId: nextVersion.Id, | ||
instanceId: importToContinue.InstanceId, | ||
cancellationToken); | ||
|
||
return new ProcessDataSetVersionResponseViewModel | ||
{ | ||
DataSetId = nextVersion.DataSetId, | ||
DataSetVersionId = nextVersion.Id, | ||
InstanceId = importToContinue.InstanceId | ||
}; | ||
}) | ||
.HandleFailuresOr(result => new OkObjectResult(result)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really thought about this until this PR, but I'm wondering if it would be better to put all this logic in a service layer, and treat this like a controller such that it isn't responsible for the business logic. But I realise we haven't been doing this everywhere currently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggesting that I absorb this change into 4954 if that's OK?
CancellationToken cancellationToken) | ||
{ | ||
const string orchestratorName = | ||
nameof(ProcessCompletionOfNextDataSetVersionFunction.CompleteNextDataSetVersionImportProcessing); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be nameof(ProcessCompletionOfNextDataSetVersionFunction.ProcessCompletionOfNextDataSetVersion)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or are we waiting until 4954 to switch it out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope you're right, it's the incorrect name here. Changed, thanks
} | ||
|
||
[Fact] | ||
public async Task DataSetVersionNotInMappingStatus_ReturnsValidationProblem() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could turn this into a [Theory]
and test every other Status
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What a fine idea, changed to a theory ta.
} | ||
|
||
[Fact] | ||
public async Task DataSetVersionImportInManualMappingStateNotFound_ReturnsValidationProblem() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
: CompleteNextDataSetVersionImportFunctionTests(fixture) | ||
{ | ||
[Fact] | ||
public async Task Success() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we could add some checks for:
- the other viewmodel properties of
responseViewModel
, to make sure they've all been set properly - grab the import from the DB, and make sure the status has been updated to
Completing
- grab the data set version from the DB, and make sure the status has been updated to
Draft
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this test doesn't actually run any of the functions in the orchestration - it just verifies that the orchestration runs through the correct list of Functions, and any updates prior to running the orchestration have been made (e.g. creating an empty DataSet before running the "initial data set version" orchestration), so there are no other db updates that would be looked for in this particular test.
I have however added in checks for the other viewmodel fields as suggested, ta.
|
||
namespace GovUk.Education.ExploreEducationStatistics.Public.Data.Processor.Tests.Functions; | ||
|
||
public abstract class ProcessCompletionOfNextDataSetVersionImportFunctionTests( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we're missing some tests for ProcessCompletionOfNextDataSetVersionFunction.CompleteNextDataSetVersionImportProcessing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haha yup, I have updated ProcessInitialDataSetVersionFunctionTests to be CompleteNextDataSetVersionImportProcessingTests, and testing the correct function method now thanks!
} | ||
} | ||
|
||
public class CompleteInitialDataSetVersionProcessingTests( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these tests should be in ProcessInitialDataSetVersionFunctionTests.cs
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haha nope, this was supposed to be CompleteNextDataSetVersionImportProcessingTests
testing the completion stage from ProcessCompletionOfNextDataSetVersionFunction
.
I have now updated thanks!
68471fe
to
1e1a27b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Look great!
…on and renaming orchestration for creating next data set version mappings, prior to adding new orchestrations
…leting processing of the next data set version.
…ion is ready to be imported after mapping is complete. Added tests around new validation and success scenarios.
…when principal entities do not exist when processing requests in the Processor project. Various renames of request classes.
1e1a27b
to
ad59299
Compare
Overview
This PR:
Other miscellaneous changes
Reusing and renaming CreateDataSetResponseViewModel
All 3 of the HTTP trigger Functions were returning the same response details, so I renamed
CreateDataSetResponseViewModel
toProcessDataSetVersionResponseViewModel
and reused across all 3. This has led to a few little changes in other miscellaneous files.New "ManualMapping" import stage
As the import process is effectively "paused" at this stage of processing until the user finishes the manual mapping, I added another stage to reflect this. Upon triggering this new orchestration, the import will "unpause" and continue to completion.
A new InstanceId will be assigned to the import entity so as not to confuse a new orchestration with an already-run one!
It didn't have to be done this way - we could also have completed the 1st import entity and then created a 2nd import entity to start off the second stage of the import, but to me personally this felt like more of an intuitive way to model it.