25 and 5 clock validator breaking at step 24 out of 29

Havent seen any posts about this specific issue, and it is a weird one.

So, to my knowledge, the program ive written works and fulfills the requirements of the project, here is a code pen of it:
Twenty-five and five-inator (codepen.io)

The problem is its breaking at step 24, seemingly by setting the session time to arbitrarily be -36. My code (as far as I am aware) doesnt allow this to happen, so it is likely something in the validator doing this

Ive added a check specifically for this oddity in order to pass the verification, all this check does is see if it has set the session length to -36 and resets the clock to a minute on each timer, the weird thing though is that I have no idea why this is happening, and I am pretty sure it isnt on my end.

A picture of it in action:

the function call to fix this is located in the tick() function, just comment out the function (you’ll know it when you see it) if you want to see how it works without the bandaid

Im more just confused what I must have done to cause this to happen, as ive looked pretty extensively and seen noone with even remotely the same issue

hello and welcome to fcc forum :slight_smile:

first of, very pretty ui, well done :clap: did you fixed this already? cause i have teried this out and it passes all test cases for me…

Ive only applied the very hacky bandaid fix, it does technically allow it to pass the tests but at least on my end I can still see it happen, even with the bandaid disabled it is only there for a second or two so it can be easy to miss

If its not happening at all then im much more confused and thats going to be a much more annoying headache

Ill try adding a button to the controls to toggle the fix or not to more easily display the problem, shouldnt take too long, and ill edit the post as well as reply again when ive added it


OK, here is a new button that enables and disables the hack fix: when its red it will fail since its not doing the specific reset, and when its green it passes the tests because the bandaid is being applied.

Just in general, I would suggest not jumping to conclusions such as tests are broken when they might in fact be surfacing bugs in the code.

When you see a specific number like that show up it isn’t random, it is the product of something. If it was a different number each time or if it happened at different times you might start to call it random. But in this case, it does not look random at all. I can guarantee you the test is not randomly setting the session timer to -36. Your code is doing that, not the tests.

If inside changeTimerLength I move the state conditions inside the setState updater function (instead of being before and depending on this.state) I pass all the tests.

Do not look unless I was not clear about what I mean
changeTimerLength(type, ammount) {
  if (type === "Break") {
    this.setState((state, props) => {
      if (
        state.breakLength + ammount <= 60 &&
        state.breakLength + ammount > 0
      ) {
        return { breakLength: state.breakLength + ammount };
  } else {
    this.setState((state, props) => {
      if (
        state.sessionLength + ammount <= 60 &&
        state.sessionLength + ammount > 0
      ) {
        return {
          sessionLength: state.sessionLength + ammount
  if (!this.state.isRunning) {
    this.setState((state, props) => ({
      currentTimeLeft: state.sessionLength * 60

Something else:

  1. Lower the setInterval delay to something fast like 50 so you do not have to wait.

  2. Set both timers to 1

  3. Run the timer and when it switches to Break pause it.

  4. Change the session timer and watch the break timer change.

Also, I don’t think you are supposed to call setState inside the setState callback (second argument function). I’m not saying it is necessarily causing issues but I’m pretty sure that isn’t the intended usage of the callback.


I see where I went wrong and was mistaken, I had not realized you were able to put full functions inside setState, and only were able to return objects; this is also why you see the setState call in the callback, although now I realize that I should have seen that was possible

I do see how the use of the setState((state) => {}) contradicts putting it inside an if statement determined by the state due to the async nature of it, which is the entire reason the former function exists

And I do agree that I jumped the gun quite a bit simply because I wasnt able to replicate it

Thank you for the feedback and examples, Ive learned quite a bit with using react due to it

Learning is the name of the game.

Even failing a project but learning something in the process is more valuable than passing and having learned nothing.

1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.