session name include the backslash "/"

Hi,
I am not sure if it is fixed in newer versions; I am currently using prodigy version 1.11.7

When we opened a session with the names x,y,z
One of the annotators uses the URL https://out.web.service:808/?session=x/
After he finished, I wanted to verify he did, so I logged into his session by https://out.web.service:808/?session=x

I was surprised to find out he didn't annotate anything. after logging into the system; I saw that the system uses x/ instead of x.

so now we two sessions session_name-x/ and session_name-x

We managed to figure everything out, but we thought we had lost a week's work. So thought it would be best to post it here for community awareness so you could fix it in the next version (if you didn't already do)

hi @shaked571!

Thanks for the details. I've made an internal note and we'll keep this in mind as we're preparing for new updates.

I would recommend setting PRODIGY_ALLOWED_SESSIONS (e.g., on your prodigy.json configuration as a control on what session names are allowed. This can prevent users from accidental mistyping unexpected session names.

As of v1.8.0, the PRODIGY_ALLOWED_SESSIONS environment variable lets you define comma-separated string names of sessions that are allowed to be set via the app. For instance, PRODIGY_ALLOWED_SESSIONS=alex,jo would only allow ?session=alex and ?session=jo , and other parameters would raise an error.

hi @ryanwesslen ,
Thanks for the reply. Maybe I wasn't clear, but I indeed used PRODIGY_ALLOWED_SESSIONS, and it still happened.
So in your example, when you apply PRODIGY_ALLOWED_SESSIONS=alex,jo it would actually allow:
?session=alex, ?session=alex/, ?session=jo and ?session=jo/

Figured I'd have a go at replicating this one. This is my command:

PRODIGY_ALLOWED_SESSIONS=alice,bob,claire python -m prodigy textcat.manual yet-another-demo examples.jsonl --label yep

When running it, it indeed seems like I can add many / characters and the UI would render just fine.

I can also confirm that this gets reflected in the annotation data via db-out.

{
  "text": "this is another one",
  "_input_hash": -1874580495,
  "_task_hash": 1574781527,
  "label": "yep",
  "_view_id": "classification",
  "answer": "accept",
  "_timestamp": 1670236717,
  "_annotator_id": "yet-another-demo-alice///",
  "_session_id": "yet-another-demo-alice///"
}

I'm pretty sure we've stumbled apon an edge case that deserves an internal ticket, because after annotating with alice///, I'm not able to annotate the same example with alice/ or alice.

I've even found that, after dropping the db, you're able to do some tomfoolery in the single session with this such that this appears in the output:

[{
  "text": "this is just one example",
  "_input_hash": 258033956,
  "_task_hash": -1451381763,
  "label": "yep",
  "_view_id": "classification",
  "answer": "accept",
  "_timestamp": 1670236886,
  "_annotator_id": "yet-another-demo-alice///",
  "_session_id": "yet-another-demo-alice///"
},{
  "text": "this is just one example",
  "_input_hash": 258033956,
  "_task_hash": -1451381763,
  "label": "yep",
  "_view_id": "classification",
  "answer": "accept",
  "_timestamp": 1670236891,
  "_annotator_id": "yet-another-demo-alice",
  "_session_id": "yet-another-demo-alice"
}]

This is without setting feed_overlap to true.

I can't put my finger on what's going wrong with the session exactly, but this deserves an investigation. I'll add a ticket. Thanks for reporting @shaked571!

1 Like