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.

Sign up for GitHub

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

Jump to bottom

Rogue UUIDs in generated ImageJ script names #80

Closed
ctrueden opened this issue May 31, 2018 · 6 comments
Closed

Rogue UUIDs in generated ImageJ script names #80

ctrueden opened this issue May 31, 2018 · 6 comments
Labels
bug
Milestone
1.0.0

Comments

@ctrueden
Copy link
Member

ctrueden commented May 31, 2018 •
edited by joshmoore
Loading

There is a sequence of characters in UUID format before each script (ex: 84f05d92-794b-11e8-bcf9-6c4008b90c48) when you run gen-scripts. These go away if you run it a second time. Maybe a sessionID?

Noticed by @awalter17.
@ctrueden ctrueden added this to the 1.0.0 milestone May 31, 2018
@ctrueden ctrueden added the bug label May 31, 2018
ctrueden added a commit that referenced this issue May 31, 2018
@ctrueden
Add a workaround for #80
cd7f658 
This doesn't get to the bottom of the issue, but it avoids the fallout.
@ctrueden
Copy link
Member Author

ctrueden commented May 31, 2018 •
edited
Loading

To be clear: the UUIDs are not in the generated script wrapper filenames, and not in the generated script wrapper contents. It only appears when you run omero script list in the output of that command. And similarly, in OMERO.web's listing. This seems like a bug in OMERO to me. What do you think, @joshmoore?

@ctrueden ctrueden changed the title Sequence of characters in generated script names Rogue UUIDs in generated ImageJ script names May 31, 2018
ctrueden added a commit that referenced this issue May 31, 2018
@ctrueden
Revert "Add a workaround for #80"
4747648 
The filenames are not the issue. The bug is that OMERO itself
(e.g., "omero script list") includes the weird UUIDs as prefixes.

This reverts commit cd7f658.
@ctrueden
Copy link
Member Author

If you run omero script list a second time, even immediately, the UUIDs are gone.

@joshmoore
Copy link
Member

@ctrueden : this is a race-condition as the server pre-processes the new scripts stemming from the migration to periodic checks in ome/openmicroscopy#3790

Calling script list after a re-deployment of the .jy files and/or restarting the server will prevent it from happening. If that's sufficient, then likely adding a workaround of 2 calls to script list as you mention is the best option.

ctrueden added a commit that referenced this issue Jun 4, 2018
@ctrueden
Add a workaround for #80
c1f9252
ctrueden added a commit that referenced this issue Jun 4, 2018
@ctrueden
WIP - Add a workaround for #80
0571977 
Needs testing. Probably won't work as written because user needs to
authenticate the first time, and piping to /dev/null will hose that.
@mtbc
Copy link

mtbc commented Jun 26, 2018 •
edited
Loading

I'll fix this for the next release of OMERO.server. You're right @ctrueden: it shouldn't be happening in the first place.

@ctrueden
Copy link
Member Author

Thanks @mtbc. I was not able to work around the issue on the ImageJ-OMERO side; the gen-scripts script would need to invoke omero script a couple of times, which would require the user to authenticate (as an admin?).

@joshmoore
Copy link
Member

Sorry for leaving this dangling. @mtbc fixed this for OMERO.server 5.4.7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
1.0.0
Development

No branches or pull requests
3 participants
@joshmoore @ctrueden @mtbc