-
Notifications
You must be signed in to change notification settings - Fork 87
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
[WIP] Feature/get exposed sql filters #215
Conversation
9d3e9d3
to
857a7e7
Compare
857a7e7
to
f653838
Compare
f653838
to
4e3844c
Compare
4e3844c
to
792995e
Compare
792995e
to
baa1f96
Compare
This PR contains also a lot of clean-up. I will remove the clean-up stuff, so that it's better visible what is done here. See #232 Update: Done... |
324b5f5
to
3b13d75
Compare
c02c522
to
a8559d1
Compare
3b13d75
to
3d02f2b
Compare
42ef973
to
d019ab7
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.
Starts looking good. I'm really not happy about the use of UTCInstant.SetClock
:
- tests cannot be run in parallel
- I'm not sure if it will not give problems in other parts of the tests
Also, UTCInstant.today()
should not be used more than once per test - even if the chance of failure is quite small.
@Test | ||
public void testNoEarlyRelease() throws Exception { | ||
Clock twoOClock = Clock.fixed(UTCInstant.today().plusHours(2).getInstant(), ZoneOffset.UTC); | ||
Clock elevenOClock = Clock.fixed(UTCInstant.today().plusHours(11).getInstant(), ZoneOffset.UTC); |
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'm not very happy with the use of setClock
in the tests - I would even remove it from UTCInstant
. Even though I'm not sure if you could still run all the tests...
Solving this and solving a very improbable race-error (UTCInstant.today()
might change during the test), could give:
start with
var today = UTCInstant.today()
use that throughout the code, and then only update now
and pass that to the methods.
Would that work? Or are there other UTCInstant.now()
and UTCInstant.today()
in the code-path?
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've discussed it with @martinalig but since it is very improbable we did not really care. It would only be a problem, iff the test is executed exactly at 00:00... but I can change it :)
List<GaenKey> keys = new ArrayList<>(); | ||
for (int i = 0; i < 30; i++) { | ||
var tmpKey = new GaenKey(); | ||
tmpKey.setRollingStartNumber((int) UTCInstant.today().minusDays(i).get10MinutesSince1970()); |
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.
Again a very improbable race-condition when using UTCInstant.today()
. You should put it at the beginning and then use today
in the code.
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 as above
Clock fourAMTomorrow = | ||
Clock.fixed(UTCInstant.today().plusDays(1).plusHours(4).getInstant(), ZoneOffset.UTC); | ||
|
||
UTCInstant.setClock(fourAMTomorrow); |
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.
To avoid this, could you pass the now
to mockMvc
?
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.
After a bit of research I think our only option would be to do something like https://github.com/raphw/byte-buddy
. I tried the Mockito
Framework, but that one only allows to replace a class with all stubs and redefine functions. I think this is not really feasible, since it would blow up the test code, since we would have to redefine all functions of the mocked class.
Also the PowerMockito
plugin seems to be rather verbose, when our only intention is to manipulate actual system time.
Another option would be to replace the static UTCInstant
approach with a singleton approach using Beans
and dependency injection. I'm not sure how easy it is to change everything and inject everywhere the Bean
(maybe with @Autowired
but then we introduce more magic...)
A way to prevent forgetting the resetClock
could be to implement the Disposable
interface and use it with a try-with
statement.
Some remarks on test parallelisation:
Since every test class itself initialises a new VM instance (and hence a new static object is instantiated) as far as I understand it, and tests aren't parallelised within test classes (this would anyways be catastrophic, since for the integration tests we relay on database inserts and then we would have to mock them as well), this should not be problematic. The only "dangerous" thing is that one could use the
setClock
function outside test-packages, which is currently not prevented (though we could check fororg.junit
being on the classPath).
Maybe I'm also completely on the wrong path here, but in my opinion it is easier that way.
@martinalig any input? :)
@@ -72,27 +72,31 @@ public void tearDown() throws SQLException { | |||
|
|||
@Test | |||
public void testFakeKeyContainsKeysForLast21Days() { | |||
Clock threeOClock = Clock.fixed(UTCInstant.today().plusHours(4).getInstant(), ZoneOffset.UTC); | |||
UTCInstant.setClock(threeOClock); |
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.
Again, can this setClock
be removed?
The other method with the incorrect sql query has been removed. |
Kudos, SonarCloud Quality Gate passed! 0 Bugs |
With the new pipeline we try to sanitise input on insert. Since due to various possible issues (and for easier debugging) we could insert keys with validity exceeding the current bucket (e.g. a key submitted today with todays keydate and rolling period 144), we additionally filter for such keys on release. Adding the rules for filtering into the SQL query should decrease the risk of accidentally releasing keys too early (e.g. bugs during insert, manipulating JWTs or other yet unknown problems).
To minmise merge conflicts, this PR depends on #213
Linted and rebased - original is at f881f56
Moved non-related changes to #234 - original is at baa1f96