Open Jwkellenberger opened 5 years ago
@Jwkellenberger Not sure if this one had been clarified in the standup on Monday.
For the URL pattern the inconsistancies are coming from the previous batches that were attempting to replicate the exact url patterns of the first version of caliber. These url patterns do not work within the updated envirment do to how the load balenced routing is setup. Therefore, using the following pattern should be the standard approach from here on out.
{ZUUL URL (ALB url when in prod)}/{service identifier}/ after the final / standard REST conventions should be followed the paths that exist that are starting with /all may be converted to this standard.
The original issue
It turns out the H2 data was fine and properly running. But, the data presenting via queries was being converted to junk values (-1) Query: http://localhost:10000/assessment/all/assessment/batch/2150?week=1
vs the data base entries:
The Culprit
I was just poking around at the controller on the Assessment service And this method verifying the data with the batch and category service was responsible for the edits: assessment-service/src/main/java/com/revature/caliber/services/AssessmentService.java
More Digging
It turns out it was not properly connecting to the batch and category service
Output logs tracking the issue
So, what could make them not connect? They seemed fine on my end? http://localhost:10003/category/12
http://localhost:10002/batch/all/batch/2150
The Simple Mistake that took too long to find
/AssessmentService/src/main/java/com/revature/caliber/intercoms/CategoryClient.java
It turns out that it is querying a method that doesn't exist on the category controller
The proper query, or at least currently implemented one is /category/{id}
Progress
The simple string swap allowed for the query to come through, at least for the category
Alas, no more -1's
Luckily, the batchid had the same issue
For the working file
assessment-service/src/main/java/com/revature/caliber/intercoms/BatchClient.java
The Result
The ability to actually progress... Whew... http://localhost:10000/assessment/all/assessment/batch/2150?week=4
Moving forward
This confirms that the previous project had some plot holes. The convention for the query followed by the Intercom client classes did not align with the queries that currently work on our active services.
Is there a desired convention that we should endeavor to uphold, and change the current query paths for the service, or are they fine as is?
@Quinn-Donnelly @rlayneorr