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

Replication events are inconsistent with their handling of `start_time` (and likely `end_time`) fields #6655

Closed
flimzy opened this Issue Jul 30, 2017 · 7 comments

Comments

Projects
None yet
2 participants
@flimzy
Contributor

flimzy commented Jul 30, 2017

Issue

Replication inconsistently uses Date objects and strings for start_time field.

Info

  • Environment: Chrome, node
  • Adapter: any, apparently
  • Server: CouchDB 1.6.1

Reproduce

Run this simple script via node (replacing the remote url with any readable, remote database):

var pouchdb = require('pouchdb');
pouchdb.replicate("http://admin:abc123@localhost:5984/user-1fbf880e-e057-41a4-b56d-6dd974c1c30d", "foo")
    .on('change', function(i) {
        console.log("change: " + i.start_time + " : " + typeof(i.start_time));
    })
    .on('complete', function(i) {
        console.log("complete: " + i.start_time + " : " + typeof(i.start_time));
    })

Observe the following output:

change: 2017-07-30T14:31:27.867Z : string
complete: Sun Jul 30 2017 16:31:27 GMT+0200 (CEST) : object

I would expect the start_time field to consistently be either a string, or a date object (ideally, a date object).

@stale

This comment has been minimized.

stale bot commented Nov 29, 2017

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Nov 29, 2017

@flimzy

This comment has been minimized.

Contributor

flimzy commented Nov 29, 2017

I would love to hear from the project maintainers/regular contributors if this is intended behavior, or if it's worth trying to fix. I imagine it's a low-priority issue, but it would probably also be relatively easy for someone familiar with the codebase.

@stale stale bot removed the wontfix label Nov 29, 2017

@daleharvey

This comment has been minimized.

Member

daleharvey commented Nov 29, 2017

Yup this isnt intended behaviour, these should be consistent. If we get any of these fields from couchdb as a string then we should match couch, if we always generated these they should probably be Dates

@daleharvey

This comment has been minimized.

Member

daleharvey commented Jan 27, 2018

Weird, we only use new Date() in replication code so they should all be objects however https://ginger-purpose.glitch.me/ shows this bug still happens

@daleharvey

This comment has been minimized.

Member

daleharvey commented Jan 27, 2018

ok this is because the change objects get cloned and during clone they lose their types, easiest just to switch to strings here

daleharvey added a commit that referenced this issue Jan 28, 2018

@daleharvey

This comment has been minimized.

Member

daleharvey commented Jan 28, 2018

@flimzy want to 👍 the PR ? then can get this merged, cheers

daleharvey added a commit that referenced this issue Jan 29, 2018

@daleharvey

This comment has been minimized.

Member

daleharvey commented Jan 29, 2018

Fixed in 6b79dbb

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment