Skip to content
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

MP import feature only shows 3 #631

Closed
vnugent opened this issue Dec 22, 2022 · 12 comments · Fixed by OpenBeta/openbeta-graphql#340
Closed

MP import feature only shows 3 #631

vnugent opened this issue Dec 22, 2022 · 12 comments · Fixed by OpenBeta/openbeta-graphql#340
Assignees
Labels
bug Something isn't working Component: Log Book Difficulty: Hard help wanted Extra attention is needed
Milestone

Comments

@vnugent
Copy link
Contributor

vnugent commented Dec 22, 2022

Expected Behavior

MP user: https://www.mountainproject.com/user/200492669/andre-chiquito
OB profile: https://openbeta.io/u/all_terrain_human

The user has over 400 ticks but it seems only 3 are imported/shown

cc @Downster

@vnugent vnugent added the bug Something isn't working label Dec 22, 2022
@vnugent vnugent added this to the v0.7 milestone Dec 22, 2022
@vnugent vnugent added the help wanted Extra attention is needed label Dec 22, 2022
@vnugent vnugent mentioned this issue Jan 5, 2023
25 tasks
@vnugent vnugent mentioned this issue Mar 3, 2023
21 tasks
@musoke
Copy link
Contributor

musoke commented Mar 12, 2023

I think I understand what happened: the importer couldn't handle the same route appearing twice in a row.

The same happened to my attempted import. The first 32 routes were fine, but the rest are missing. The 33rd tick in my logbook is of the same route as the 32nd.

Judging by the dates on this issue and their logbook, these were the three most recent routes at the time of the attempted import:

Left Of Time
The Twins Right
Hardman
Hardman
Mr. Aidman's Free
Black Hole

These are the three ticks imported successfully:

The Twins Right
Hardman
Left Of Time

It seems to have failed when it saw the second Hardman.

@musoke
Copy link
Contributor

musoke commented Mar 12, 2023

I suspect that this is related to the error message that appears when attempting to log multiple ticks on the same day through the web interface.

image

Is there a reason for that being disallowed? I often do a climb more than once in a day.

@vnugent
Copy link
Contributor Author

vnugent commented Apr 18, 2023

Is there a reason for that being disallowed? I often do a climb more than once in a day.

I think due to date string being used as the unique constraint: OpenBeta/openbeta-graphql#175

@musoke
Copy link
Contributor

musoke commented Apr 18, 2023 via email

@musoke
Copy link
Contributor

musoke commented Apr 18, 2023

In any case, the importer should probably attempt to continue after encountering an error with individual ticks.

@milbmr
Copy link
Contributor

milbmr commented Apr 29, 2023

I want to work at this issue but i need API keys to access users Profile.

@vnugent
Copy link
Contributor Author

vnugent commented May 1, 2023

I want to work at this issue but i need API keys to access users Profile.

@milbmr
can you please send me an email: viet at openbeta dot io

@musoke
Copy link
Contributor

musoke commented Jul 13, 2023

I have another datapoint:

I imported the following log book:
image
It has two pairs out routes, each ticked twice on one day.

  1. The first pair has different style.
  2. The second pair has the same style.

Here's the list of ticks as reported by https://stg-api.openbeta.io:

{
  "data": {
    "userTicks": [
      {
        "_id": "64afe8808827f07ef7253506",
        "userId": "c26b3c91-bb05-42a9-8f8c-b2209c55781b",
        "name": "Lemonade",
        "notes": "",
        "climbId": "6cf437fa-027c-52ba-b0f0-7eda58fa4a2b",
        "style": "N/A",
        "attemptType": "N/A",
        "dateClimbed": 1682899200000,
        "grade": "V5",
        "source": "MP"
      },
      {
        "_id": "64afe8808827f07ef7253507",
        "userId": "c26b3c91-bb05-42a9-8f8c-b2209c55781b",
        "name": "Lemonade",
        "notes": "",
        "climbId": "6cf437fa-027c-52ba-b0f0-7eda58fa4a2b",
        "style": "Attempt",
        "attemptType": "Attempt",
        "dateClimbed": 1682899200000,
        "grade": "V5",
        "source": "MP"
      },
      {
        "_id": "64afe8808827f07ef7253508",
        "userId": "c26b3c91-bb05-42a9-8f8c-b2209c55781b",
        "name": "Cream Cheese",
        "notes": "",
        "climbId": "921a5290-a42e-5aec-8c67-f8d9fe4b01c8",
        "style": "Flash",
        "attemptType": "Flash",
        "dateClimbed": 1680307200000,
        "grade": "V6",
        "source": "MP"
      }
    ]
  }
}

The first pair imports successfully, the second does not.
It would seem that it is the combination of same day and style that fails. Differentiating by "notes" does not help.

@musoke
Copy link
Contributor

musoke commented Jul 13, 2023

I get this error when doing the import on a local dev open-tacos instance with the prod backend.

Unhandled Runtime Error

ApolloError: E11000 duplicate key error collection: openbeta.ticks index: climbId_1_dateClimbed_1_style_1_userId_1_source_1 dup key: { climbId: "921a5290-a42e-5aec-8c67-f8d9fe4b01c8", dateClimbed: new Date(1680321600000), style: "Flash", userId: "c26b3c91-bb05-42a9-8f8c-b2209c55781b", source: "MP" }


Call Stack
ApolloError
node_modules/@apollo/client/errors/index.js (26:0)
QueryManager.prototype.mutate/</</</<
node_modules/@apollo/client/core/QueryManager.js (97:0)
both
node_modules/@apollo/client/utilities/observables/asyncMap.js (16:45)
then/<
node_modules/@apollo/client/utilities/observables/asyncMap.js (9:56)
then
node_modules/@apollo/client/utilities/observables/asyncMap.js (9:0)
makeCallback/<
node_modules/@apollo/client/utilities/observables/asyncMap.js (17:0)
notifySubscription
node_modules/zen-observable-ts/module.js (132:0)
onNotify
node_modules/zen-observable-ts/module.js (176:0)
next
node_modules/zen-observable-ts/module.js (225:0)
iterateObserversSafely/<
node_modules/@apollo/client/utilities/observables/iteration.js (4:49)
iterateObserversSafely
node_modules/@apollo/client/utilities/observables/iteration.js (4:0)
next
node_modules/@apollo/client/utilities/observables/Concast.js (25:42)
notifySubscription
node_modules/zen-observable-ts/module.js (132:0)
onNotify
node_modules/zen-observable-ts/module.js (176:0)
next
node_modules/zen-observable-ts/module.js (225:0)
next
node_modules/@apollo/client/link/error/index.js (29:0)
notifySubscription
node_modules/zen-observable-ts/module.js (132:0)
onNotify
node_modules/zen-observable-ts/module.js (176:0)
next
node_modules/zen-observable-ts/module.js (225:0)
readJsonBody/<
node_modules/@apollo/client/link/http/parseAndCheckHttpResponse.js (144:0)

@vnugent
Copy link
Contributor Author

vnugent commented Jul 13, 2023

I see what's going on now. The database has a unique constraint on climb, date, style, user, source to prevent the same tick from being imported multiple times. We can think of some other way to address re-import use case.

TickSchema.index({ climbId: 1, dateClimbed: 1, style: 1, userId: 1, source: 1 }, { unique: true })

https://github.com/OpenBeta/openbeta-graphql/blob/develop/src/db/TickSchema.ts#L27

@musoke
Copy link
Contributor

musoke commented Jul 13, 2023

I think the current implementation deletes previously imported ticks before doing the new import, so one can probably disable this addition check for now? Double check this.

@vnugent
Copy link
Contributor Author

vnugent commented Jul 13, 2023

You're right. The import deletes all previous ones. We can change the indexes to something like this:

TickSchema.index({ userId: 1 }) // ticksByUser()
TickSchema.index({ climbId: 1, userId: 1 }) // for ticksByUserIdAndClimb()

@musoke musoke self-assigned this Jul 13, 2023
musoke added a commit to musoke/openbeta-graphql that referenced this issue Jul 13, 2023
The schema enforces a unique index on {climbId, dateClimbed, style,
userID, source}.  This is meant to prevent duplicating ticks imported
from mountain project.  However, it also prevents logging such ticks
when they are legitimate.

The import procedure also deletes imported ticks before reimporting, so
this was overly cautious.

Change the schema so it does not enforce uniqueness in this way.
Instead, add non-unique indexes on { userId } and { userId, climbId }.

Add a db migration script.

Remove climb uniqueness test.

Fixes OpenBeta/open-tacos#631
vnugent pushed a commit to OpenBeta/openbeta-graphql that referenced this issue Jul 13, 2023
The schema enforces a unique index on {climbId, dateClimbed, style,
userID, source}.  This is meant to prevent duplicating ticks imported
from mountain project.  However, it also prevents logging such ticks
when they are legitimate.

The import procedure also deletes imported ticks before reimporting, so
this was overly cautious.

Change the schema so it does not enforce uniqueness in this way.
Instead, add non-unique indexes on { userId } and { userId, climbId }.

Add a db migration script.

Remove climb uniqueness test.

Fixes OpenBeta/open-tacos#631
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Component: Log Book Difficulty: Hard help wanted Extra attention is needed
Projects
Development

Successfully merging a pull request may close this issue.

3 participants