Skip to content

Add StatusResponse class to handle successful response messages #1167

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

Merged
merged 41 commits into from
Jul 11, 2025

Conversation

rohaan-rma
Copy link
Contributor

@rohaan-rma rohaan-rma commented Jul 1, 2025

Fixes #1112

  • Added StatusResponse class -> office-id, message and identifier String fields
  • Added basic serialization/deserialization unit tests
  • Add office-id back, thus make StatusResponse extend CwmsDTO (all use cases of StatusResponse have an office)
  • Changing HTTP status codes 204 -> 200 to allow for a response body containing simple message and information of what was deleted. Update tests and OpenApi docs too.
  • TurbineController
  • LevelsController
  • LocationController
  • EmbankmentController
  • StreamLocationController
  • StreamController
  • BasinController
  • LookupTypeController
  • WaterContractController
  • WaterUserController
  • LockController
  • PropertyController
  • MeasurementController
  • OutletController

Saving the last 5 tasks for a separate PR (This one is too long already)

  • VirtualOutletController
  • AccountingCreateController
  • RatingController
  • TurbineChangesController
  • StreamReachController

@rohaan-rma rohaan-rma changed the title Add StatusResponse class to handle successful JSON messages Add StatusResponse class to handle successful response messages Jul 1, 2025
@Test
void createStatusResponse_allFieldsProvided_Success() {
// all three fields provided
StatusResponse item = new StatusResponse("TestOffice", "TestMessage", "TestIdentifier123");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use "real" data.... At least for the office anyways. I get a real "message" could be a bit tricky.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, used more realistic test data names.

@@ -0,0 +1,5 @@
{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we actually want the officeID, there's a "CwmsBaseDTO" that CwmsDTO Derives from that intentionally doesn't include the office-id field.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm trying to include some relevant data other than just the response message. I assumed an office-id would be helpful to have, but I'm open to getting rid of it if we think it's unnecessary. Perhaps there's some more specific data that would be better to include instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you look at CdaError it contains a Map field for additional data.
... might also be worth seeing if that just needs a better name, like CdaResponse, in instead of error.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I've been looking at the CdaError class. I do think I can rework/use that class to become a general message response class. Although the incidentIdentifier field in that class would be a little useless for successful responses since there won't be any error logging.

I guess this begs the question of whether or not we want to create a new class for general messages or whether or not we want to reuse the CdaError class and put some information in the details map. I think either way is probably fine.

Also, I rewrote some messages in the TurbineController class as an example of how the current StatusResponse class would be used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that I've worked further, I believe the two most important fields to report are the message itself and a name or ID of what was changed (created, updated, or deleted).

While it was possible to rework the CdaError class to be more generalized, I don't think that this basic status response class needs a details map or an incident identifier for error logs. Having separate classes for errors and successful responses also seems to make more sense.

Also, since there are a lot of files to update, it may be better to get this PR merged first and then I can make separate PRs to update the rest of the codebase. This might make things easier on reviewers as well.

@adamkorynta adamkorynta self-requested a review July 3, 2025 18:56
Copy link
Contributor

@MikeNeilson MikeNeilson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do not add additional controller changes to this PR. It's already rather long.

@MikeNeilson
Copy link
Contributor

Please do not add additional controller changes to this PR. It's already rather long.

For clarity I mean updates to the new scheme, fixes and additional change may be expected.

@FormattableWith(contentType = Formats.JSONV1, formatter = JsonV1.class, aliases = {Formats.DEFAULT, Formats.JSON})
@JsonInclude(JsonInclude.Include.NON_NULL)
@JsonNaming(PropertyNamingStrategies.KebabCaseStrategy.class)
public final class StatusResponse extends CwmsDTO{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why was this set back to CwmsDTO from CwmsDTOBase?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We looked over everything again, and decided that the office-id field is useful to include since almost everything is office specific. There was really no additional overhead to requiring the office-id field.

Also, every controller has an office-id with easy access. I checked all the instances of where I'm going to be implementing StatusResponse and I couldn't find a case where I wouldn't be able to grab an office-id.

@rohaan-rma rohaan-rma marked this pull request as ready for review July 8, 2025 18:28
@rohaan-rma rohaan-rma requested a review from zack-rma July 9, 2025 17:00
Copy link
Collaborator

@zack-rma zack-rma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good

@rohaan-rma rohaan-rma requested a review from MikeNeilson July 9, 2025 23:02
@MikeNeilson MikeNeilson merged commit 4f5a6f1 into USACE:develop Jul 11, 2025
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Invalid response JSON format, mismatched response and documentation
4 participants