Found an (apparent) bug in javascript execution

Feedback
1

Hi there!

I maintain a javascript/typescript library for dealing with recurring dates, rSchedule (which this forum won’t let me link to). A user reached out to me with some usage questions. The user is (I think) also learning javascript and they’ve been practicing / testing things out using this website (which I’ve never heard of before). While using this website to demonstrate rSchedule usage for this user, it appears I’ve found a bug.

See this example project I created on this website: the last “cell” (? not sure if that’s the proper word) is equal to an empty array. You can see the same example on codesandbox where the equivalent line produces an array containing a single date (the expected result). Without delving into whether there is a bug with my library (I don’t think there is in this case), hopefully we can all agree that these two examples should produce the same result.

Figured someone would want me to report this.
Thanks!

ps: you can find a link to the rSchedule repo on the “Observable” example I created, as well as by looking at the npm modules in the codesandbox example.

2 Likes
2

To help with debugging, I’ll note that if you change the last cell from this:

schedule
  .occurrences({reverse: true, end: new Date(), take: 1 })
  .toArray()
  .map(adapter => adapter.date.toLocaleString());

to this:

schedule
  .occurrences({reverse: true, end: start, take: 1 })
  .toArray()
  .map(adapter => adapter.date.toLocaleString());

It produces the expected result.

3

So the difference boils down to Date, right? Can you share a reduced example that only compares new Date and date.toLocaleString?

4

I’m not sure what you mean? Do you mean ~ “can I share the difference between end: new Date() and end: start?”

start stringifies to 2019-07-17T00:00 and new Date() (at this moment) stringifies to 2019-07-17T05:38:53.312.

5

It might be worth noting that the examples in your initial post are not equivalent. To create an apt comparison you have to run the code in a single cell, like you do on codesandbox.io.

The execution order of cells is not determined by their order in the notebook.

6

Interesting, that is worth noting. Do you have a suggestion for how I can perform the appropriate test on codesandbox (or my local machine)?

Seperately, does that mean that the schedule variable (used in the last cell) might be undefined when the last cell is called?

7

I edited both examples to remove some bits that were unnecessary.

8

Promises and dependency injection should work. I also recommend reading

The cell has an explicit dependency on schedule, so schedule is guaranteed to run first. What happens after (or inside) is up the script (unless you return a promise). However, the last cell is not guaranteed to run last.

1 Like
9

Please also make sure that both the sandbox and the notebook pull in the exact same scripts, from the exact same sources. The best way to verify (in my opinion) is to check the network tab in your browser’s developer tools.

10

That’s some good advice, but I think this is going to be just a bit too much work for me to help out a website I’m not invested in.

I was originally intending for this to be more of an FYI. If this isn’t an issue that bothers you, feel free to close it.

At the moment, I’m convinced this isn’t a bug within rSchedule. If in the future I find out otherwise, I’ll come back and update this post.

:+1:

11

Here’s a reproduction of your bug in a vanilla JavaScript browser environment:

https://bl.ocks.org/mbostock/raw/0601d1ddbe084aab7eff885dd5cbf79d/

And here’s a reproduction of your bug in a simple node script:

So, this is clearly not an issue with Observable. I’m not sure why the behavior is different on CodeSandbox, but Observable’s behavior is here consistent with both vanilla JavaScript and Node.

3 Likes
12

The reason this passes on CodeSandbox is that you pinned the version of rschedule to 0.11.0. If you upgrade to 0.11.1 or 0.11.2 you should see the same bug. Edit: here is a suggestion to pin the version.

3 Likes
13

You are correct! I also see that my Observable example works when the version is pinned to 0.11.0. I’ll figure out what caused this regression and why it wasn’t picked up by any tests.

Very sorry for wasting your time! It makes sense, when I think about it, that codesandbox would always pin the module version, but I didn’t realize that it did so.