GraceDB Server issueshttps://git.ligo.org/computing/gracedb/server/-/issues2022-04-04T14:37:45Zhttps://git.ligo.org/computing/gracedb/server/-/issues/220"terminating connection due to administrator command"2022-04-04T14:37:45ZAlexander Pace"terminating connection due to administrator command"Over the weekend (April 3-4), I woke up to about ~30 emails from `gracedb-test/playground` and then the following day, from `gracedb` (production) with the following error message:
```
Internal Server Error: /some/api/path
OperationalE...Over the weekend (April 3-4), I woke up to about ~30 emails from `gracedb-test/playground` and then the following day, from `gracedb` (production) with the following error message:
```
Internal Server Error: /some/api/path
OperationalError at /some/api/path
terminating connection due to administrator command
SSL connection has been closed unexpectedly
```
Okay? I had never seen that before. So it appears to be a thing with postgres/RDS. ex: https://old.reddit.com/r/aws/comments/b5l3ha/rds_giving_terminating_connection_due_to/
I went into the management console and saw messages like this for "recent events":
![Screen_Shot_2022-04-04_at_10.28.21_AM](/uploads/6eafa63e416711b680f8db37bf87f369/Screen_Shot_2022-04-04_at_10.28.21_AM.png)
So the best I can gather from that and from the maintenance settings is that RDS triggered a minor version update and shutdown and restarted the databases automatically. Client connections were closed, and that's what caused the errors. So as a first cut, I disabled automatic updates, so that's something to keep an eye on for maintenance windows.
I also ducked into sentry and saw that gwcelery recorded the 500 httperror messages, so the clients saw it as well. Hopefully this doesn't pop up again. But i'm recording it here just in case.
Also, the line `SSL connection has been closed unexpectedly`.
For some reason by default postgres asks for an SSL connection? All the communication between the database and the EC2 nodes is behind the cloud and constrained to security groups, so I think we could get away with disabling it and reducing the connection overhead: https://www.postgresql.org/docs/current/libpq-ssl.htmlhttps://git.ligo.org/computing/gracedb/server/-/issues/219Port labels from catalog-dev2023-07-21T15:10:39ZAlexander PacePort labels from catalog-devPlease prepare a list of labels that are on `catalog-dev.lig.org` that will need to be in place on GraceDB to transfer events and shut down `catalog-dev`. As a first cut, I came up with:
```
In [1]: from ligo.gracedb.rest import GraceD...Please prepare a list of labels that are on `catalog-dev.lig.org` that will need to be in place on GraceDB to transfer events and shut down `catalog-dev`. As a first cut, I came up with:
```
In [1]: from ligo.gracedb.rest import GraceDb
In [2]: cdev = GraceDb('https://catalog-dev.ligo.org/api/')
In [3]: gdb = GraceDb('https://gracedb.ligo.org/api')
In [4]: catalog_dev_labels = cdev.allowed_labels
In [5]: gracedb_labels = gdb.allowed_labels
In [6]: set(catalog_dev_labels) - set(gracedb_labels)
Out[6]:
{'CHUNK_1',
'CHUNK_10',
'CHUNK_11',
'CHUNK_12',
'CHUNK_13',
'CHUNK_14',
'CHUNK_15',
'CHUNK_16',
'CHUNK_17',
'CHUNK_18',
'CHUNK_19',
'CHUNK_2',
'CHUNK_20',
'CHUNK_21',
'CHUNK_22',
'CHUNK_23',
'CHUNK_24',
'CHUNK_25',
'CHUNK_26',
'CHUNK_27',
'CHUNK_28',
'CHUNK_29',
'CHUNK_3',
'CHUNK_30',
'CHUNK_31',
'CHUNK_32',
'CHUNK_33',
'CHUNK_34',
'CHUNK_35',
'CHUNK_36',
'CHUNK_37',
'CHUNK_38',
'CHUNK_39',
'CHUNK_4',
'CHUNK_40',
'CHUNK_5',
'CHUNK_6',
'CHUNK_7',
'CHUNK_8',
'CHUNK_9',
'CHUNK_UNKNOWN',
'DETCHAR_NO',
'DETCHAR_YES',
'DQ_NO',
'DQ_YES',
'FINAL',
'GDB_NO',
'GDB_YES',
'NONE',
'O3A_CAT_NO',
'O3A_CAT_YES',
'O3A_CBC_CATALOG',
'O3A_CBC_FINAL',
'O3A_CBC_SUBTHRESHOLD',
'O3A_CWB_FINAL',
'O3A_CWB_ONLY',
'O3A_EVENT_FOR_O3B',
'O3A_SSM',
'O3B_CBC_CATALOG',
'O3B_CBC_SUBTHRESHOLD',
'O3B_CWB_ONLY',
'O3B_SSM',
'PE_NO',
'PE_YES',
'PRELIM'}
```
I think some thought needs to be given in terms of which ones to retain and which ones aren't necessary. For instance at first glance `NONE`, `GDB_NO`, `GDB_YES` probably don't make sense in the context of using GraceDB as the final event repository.
Once I get the list, I can add them to gracedb's deployment for testing.
@gregory.ashton @surabhi.sachdev @rebecca.ewingO4 CBC ImprovementsAlexander PaceAlexander Pacehttps://git.ligo.org/computing/gracedb/server/-/issues/218Validate the CBC meta data2022-03-15T10:31:20ZGregory Ashtongregory.ashton@ligo.orgValidate the CBC meta dataThe uploaded meta data #217 can be validated by the [JSON schema](https://git.ligo.org/cbc/meta-data/-/blob/main/cbc-meta-data.schema). Note this is not yet complete. A v1 draft is in preparation.The uploaded meta data #217 can be validated by the [JSON schema](https://git.ligo.org/cbc/meta-data/-/blob/main/cbc-meta-data.schema). Note this is not yet complete. A v1 draft is in preparation.https://git.ligo.org/computing/gracedb/server/-/issues/217Enable the upload of CBC meta data2022-03-15T21:51:29ZGregory Ashtongregory.ashton@ligo.orgEnable the upload of CBC meta data## Description of feature request
<!--
Describe your feature request!
Is it a web interface change? Some underlying feature? An API resource?
The more detail you can provide, the better.
-->
## Use cases
The CBC group would like to be ...## Description of feature request
<!--
Describe your feature request!
Is it a web interface change? Some underlying feature? An API resource?
The more detail you can provide, the better.
-->
## Use cases
The CBC group would like to be able to upload a CBC meta-data JSON object (see https://git.ligo.org/cbc/meta-data/-/blob/main/cbc-meta-data-example.json for an example)
## Benefits
The CBC group will be able to track the workflow of products
## Drawbacks
<!--
Are there any drawbacks to adding this feature?
Can you think of any ways in which this will negatively affect the service for any set of users?
-->
## Suggested solutions
<!-- Do you have any ideas for how to implement this feature? -->O4 CBC Improvementshttps://git.ligo.org/computing/gracedb/server/-/issues/216Superevents: show preferred event(s) by pipeline2023-05-31T11:35:52ZAlexander PaceSuperevents: show preferred event(s) by pipelinevia the [AllSky LVK session](https://docs.google.com/document/d/1_EJWjWSsVbSG-ayvUGh61o0ITH0E-QCjdiwN_g6zU90/edit#heading=h.u1fpy3azpe8y):
> Pipelines must be able to identify a single preferred trigger if multiple have been uploaded to...via the [AllSky LVK session](https://docs.google.com/document/d/1_EJWjWSsVbSG-ayvUGh61o0ITH0E-QCjdiwN_g6zU90/edit#heading=h.u1fpy3azpe8y):
> Pipelines must be able to identify a single preferred trigger if multiple have been uploaded to GraceDB
This could be as simple as having a table on a superevent landing page that scrapes the min-far/snr candidate for each pipeline and gives a link.
Alternatively, there could be a dedicated db table (`superevent_pipelinepreferred` or something like that) where each pipeline has its row with a foreign key entry that links to a pipeline's event. I think this is a valid approach that I can implement, as it would also return preferred events in igwn-alerts and API responses. The question there is, how does that table get populated?
For reference, there is no internal logic for defining a preferred event _in GraceDB_. `GWCelery` picks the preferred event.
1) Should the responsibility for defining a pipeline's preferred event be part of the pipeline? So at upload time, there could be an extra API call... `client.set_as_pipeline_preferred(superevent_id, pipeline, event_id`. The issue for doing this would be defining new groups and permissions. Or, if a user/robot has permission to populate a pipeline, then they can choose preferred events.
2) Have `GWCelery` (who is receiving alerts and filtering events already) by FAR/SNR and pipeline define it. This could be part of the superevent manager's logic. This kind of seems to be the natural choice to me.
3) Have `GraceDB` pick it. This requires more logic and selection criteria to be implemented and updated as the subject to the CBC and low-latency group's caprice. Then external groups need to define what the individual preferred selection criteria.
Personally I'm in favor of #2 (having the superevent manager choose the pipeline preferred event) as it is most parallel with what is being done currently.
Tagging some relevant parties:
@ian-harry, @erik-katsavounidis, @shaon.ghosh, @roberto.depietriCritical Path O4 DevelopmentAlexander PaceAlexander Pacehttps://git.ligo.org/computing/gracedb/server/-/issues/215Enable MLy pipeline2022-04-01T15:09:52ZAlexander PaceEnable MLy pipelineThere a request from @kyle.willetts, @patrick-sutton to enable `MLy` uploads to gracedb, so this ticket is designed to track that work. The sample upload is here:
[mock_event.json](/uploads/2d22376569f73878d47fd56bd449c89d/mock_event.js...There a request from @kyle.willetts, @patrick-sutton to enable `MLy` uploads to gracedb, so this ticket is designed to track that work. The sample upload is here:
[mock_event.json](/uploads/2d22376569f73878d47fd56bd449c89d/mock_event.json)
Steps on my part are (roughly) to:
1) Make the new pipeline object and store in a migration. Any `MLy` developer should be able to upload `Test` events, so uploaders/robots can be defined later.
2) Modify [view_logic.py](https://git.ligo.org/computing/gracedb/server/-/blob/master/gracedb/events/view_logic.py#L42) and assign the pipeline an event type.
3) Modify [translator.py](https://git.ligo.org/computing/gracedb/server/-/blob/master/gracedb/events/translator.py) to parse the json file and then store it in the db.
4) Modify [view_utils.py](https://git.ligo.org/computing/gracedb/server/-/blob/master/gracedb/events/view_utils.py) to serialize `MLy` events into igwn-alerts and API responses.
5) Create a new view template with tables to show web results.
The last step is to add uploaders and robots to push events in production.Alexander PaceAlexander Pacehttps://git.ligo.org/computing/gracedb/server/-/issues/214Free-naming of confirmed GW's2022-11-18T13:53:45ZAlexander PaceFree-naming of confirmed GW'simplemented on catalog-dev, but never ported over :upside_down:
I think some combination of this commit:
https://git.ligo.org/computing/gracedb/server/-/commit/8eec380845d44a01adbf6d94b6f93617716b751c
and this one:
https://git.ligo...implemented on catalog-dev, but never ported over :upside_down:
I think some combination of this commit:
https://git.ligo.org/computing/gracedb/server/-/commit/8eec380845d44a01adbf6d94b6f93617716b751c
and this one:
https://git.ligo.org/computing/gracedb/server/-/commit/ac510c3c48a1d927d51f6289b70c8cec77ff668b
Should allow for free-naming of GWs, which is a long-time request.
Also this makes it modifiable with the API: https://git.ligo.org/computing/gracedb/server/-/commit/3c8e1148c3d0948b711dbd7a6407d06742f2a38d
There should probably be a user/group constraint that limits the permissions on that last one.O4 CBC ImprovementsDuncan MeacherDuncan Meacherhttps://git.ligo.org/computing/gracedb/server/-/issues/213Superevent "flattening"2022-03-18T01:03:59ZAlexander PaceSuperevent "flattening"I was really bad about documenting commits on this branch: https://git.ligo.org/computing/gracedb/server/-/tree/new_event_superevent_types
But basically it entailed "flattening" the table structure for superevents, such that the `supere...I was really bad about documenting commits on this branch: https://git.ligo.org/computing/gracedb/server/-/tree/new_event_superevent_types
But basically it entailed "flattening" the table structure for superevents, such that the `superevent_id` was no longer a python property constructed from the date id and such. This will go a LONG way to improve page load times and superevent queries. It also cuts down on a bunch of regex's throughout the code that decomposed the superevent_id back into dateids.
I had used the [django-computedfields](https://pypi.org/project/django-computedfields/) package that worked pretty well. But maybe there's a more postgres-y way to do this.
Also since events' GIDs are constructed from one letter already in the database along with a row id, I think we basically get graceid's in the database for free as well.O4 CBC Improvementshttps://git.ligo.org/computing/gracedb/server/-/issues/212Metadata for triggers and candidate events2022-03-22T13:38:22ZAlexander PaceMetadata for triggers and candidate eventsThe [charge](https://dcc.ligo.org/LIGO-T2100502) for O4 data product management states:
> Metadata: We define metadata as a set of lightweight data products or links to data products
associated with a given trigger. For example, lightwe...The [charge](https://dcc.ligo.org/LIGO-T2100502) for O4 data product management states:
> Metadata: We define metadata as a set of lightweight data products or links to data products
associated with a given trigger. For example, lightweight data products such as the FAR and SNR or
paths links to parameter estimation posteriors.
I think this can be accomplished with a new table that's linked with a 1:1 foreign key to a g-event. Also from the charge, a proposed format the metadata is below. Inserted as a screenshot since copy/paste from pdf totally gnarled up the formatting.
![Screen_Shot_2022-02-28_at_9.29.27_PM](/uploads/92a3e044fab88bcb533741c5f9604d15/Screen_Shot_2022-02-28_at_9.29.27_PM.png)
I think a first cut would involve taking advantage of postgres' [json datatype](https://www.postgresql.org/docs/9.4/datatype-json.html).
Querying for metadata would have to be implemented too.O4 CBC Improvementshttps://git.ligo.org/computing/gracedb/server/-/issues/211Add SciTokens support2023-07-17T15:07:39ZDuncan Macleodduncan.macleod@ligo.orgAdd SciTokens supportThe GraceDB server needs to accept a SciToken as an authorisation option.The GraceDB server needs to accept a SciToken as an authorisation option.O4 AdvanceDuncan MeacherDuncan Meacherhttps://git.ligo.org/computing/gracedb/server/-/issues/210Reducing queries by packing igwn-alert2022-03-18T01:03:58ZAlexander PaceReducing queries by packing igwn-alertAs discussed on low-latency call, December 8 2021. The purpose of this ticket is to solicit feedback and suggestions for what information to include in `igwn-alert` packets with the goal of reducing costly queries to GraceDB.
Relevant p...As discussed on low-latency call, December 8 2021. The purpose of this ticket is to solicit feedback and suggestions for what information to include in `igwn-alert` packets with the goal of reducing costly queries to GraceDB.
Relevant past commits:
* https://git.ligo.org/lscsoft/gracedb/-/commit/e52b0c2ea248efbbb221ed51c58d55a3e5c4a3de
* https://git.ligo.org/lscsoft/gracedb/-/commit/2402e914dd6afd28035f6d06086bd6519f8018a9
Current MR's:
* https://git.ligo.org/lscsoft/gracedb/-/merge_requests/52/O4 Infrastructure ImprovementsAlexander PaceAlexander Pacehttps://git.ligo.org/computing/gracedb/server/-/issues/209Re-enable X-Pipeline2023-02-22T15:36:48ZAlexander PaceRe-enable X-Pipeline**Background:** `X-Pipeline` or just `X` has been floating around in GraceDB since way before I've been on this project, but has [never uploaded an event](https://gracedb.ligo.org/search/?query=X&query_type=E&results_format=S). I was att...**Background:** `X-Pipeline` or just `X` has been floating around in GraceDB since way before I've been on this project, but has [never uploaded an event](https://gracedb.ligo.org/search/?query=X&query_type=E&results_format=S). I was attempting to clean up event logic back in mid 2020, and so I added `X`, `Q`, and `Omega` pipelines to a list of pipelines that were being phased out, and [returned a warning message](https://git.ligo.org/lscsoft/gracedb/-/blob/ca14eb8e8eb0c4111ecac38d6e879472fea1b111/gracedb/api/v1/events/views.py#L524-L525) if a user attempted to upload an event to that pipeline. Not that it would have worked anyway, because the [logic](https://git.ligo.org/lscsoft/gracedb/-/blob/master/gracedb/events/view_logic.py#L66-L67) to ingest X-pipeline event files had never actually been implemented and likely would have returned an error.
I received a request over [mattermost](https://chat.ligo.org/ligo/pl/t1zgpxrm8fdz8qk4xrk4jiueby) to revive the pipeline.
Before proceeding with this, I need from @amber-stuver:
1) An example event upload. I don't know the output file format (xml? json?) or what fields that are in the file should be stored in the database. I can look it over as a first step to compare to other event types that are in GraceDB, but I need the file first and foremost. It can be attached to this ticket.
2) What kind of search type is it? Right now, GraceDB ingests events from `CoincInspiral` searches, `GRB` searches, `Multiburst` searches, etc. If `X` fits into one of those categories, storing event data and constructing the view and `REST` response is simpler. But this will make more sense when I get the example upload.
3) Who is going to be uploading and populating the pipeline? If it's individual users, I need just your `@LIGO.org` email address. Or, if there is a robot account that is uploading, please apply for a cert from https://robots.ligo.org/ and then I'll add it as an uploader.
Once I get the example upload and the other information that I need, the steps I need to do are:
1) Remove `X` from the depreciated pipelines list.
2) Add logic to `view_logic.py` to read in `X` events.
3) Determine views for `X` events, add it to settings.
4) Add uploader permissions for the pipeline
5) Test event uploads, ingestion into the database, and webpage views.
6) Make appropriate LVAlert topics for `X-pipeline`
Then I'll have to push a server code change and deploy it.
Drop any questions or sample files you have here and I'll get back to you.Alexander PaceAlexander Pacehttps://git.ligo.org/computing/gracedb/server/-/issues/208Request to change sname format2021-11-01T15:17:31ZGregory Ashtongregory.ashton@ligo.orgRequest to change sname format## Description of feature request
Change the sname format from `SYYMMDDabc` to `SYYMMDD_HHMMSSabc`
## Use cases
## Benefits
<!-- Describe the benefits of adding this feature -->
For anyone relating events from papers to GraceDB, th...## Description of feature request
Change the sname format from `SYYMMDDabc` to `SYYMMDD_HHMMSSabc`
## Use cases
## Benefits
<!-- Describe the benefits of adding this feature -->
For anyone relating events from papers to GraceDB, this removes ambiguity and the need to remember which sname maps to which GW name. Or, at least it reduces the number of cases (I think to zero with good confidence, though there could be edge cases).
## Drawbacks
<!--
Are there any drawbacks to adding this feature?
Can you think of any ways in which this will negatively affect the service for any set of users?
-->
snames become longer and "uglier". However, the choice for GW names to be long and ugly has already been made. So this just provides better consistency.
## Suggested solutions
<!-- Do you have any ideas for how to implement this feature? -->
For O4 onwards only. Though, it could also be applied retroactively to GW events not in GraceDB already.Alexander PaceAlexander Pacehttps://git.ligo.org/computing/gracedb/server/-/issues/207GraceDB considerations before Oct. 2021 MDC2021-10-05T01:37:24ZAlexander PaceGraceDB considerations before Oct. 2021 MDCI would like to be on the same page and tie up some loose ends before October 2021's MDC event. Specifically, please confirm that pipelines and GWCelery will be using the `gracedb-playground` and `lvalert-playground` infrastructure.
Ad...I would like to be on the same page and tie up some loose ends before October 2021's MDC event. Specifically, please confirm that pipelines and GWCelery will be using the `gracedb-playground` and `lvalert-playground` infrastructure.
Additionally, could pipeline head please confirm which `search`es they will be using for event uploads? I will then confirm that the appropriate LVAert nodes are in place to send messages?
Thanks. I'll add more to this ticket as they come up.
`CWB`, `gstlal`, `MBTAOnline`, `oLIB`, `pycbc`, `spiir`https://git.ligo.org/computing/gracedb/server/-/issues/206Proposals and comments for public release of data products2022-08-03T18:46:59ZAlexander PaceProposals and comments for public release of data productsTicket to track discussion regarding O4 release of low-latency data products.
Please refer to the minutes from day-one of the low-latency virtual face-to-face on September 15, 2021 [here](https://docs.google.com/document/d/1L0hLw1A3H20...Ticket to track discussion regarding O4 release of low-latency data products.
Please refer to the minutes from day-one of the low-latency virtual face-to-face on September 15, 2021 [here](https://docs.google.com/document/d/1L0hLw1A3H20Xphjj4vhuN7aLWd2roTmpwDav9PUzNXM/edit#).
In particular, the way public exposure of data products works currently is:
- Only information on a _superevent_'s page is made public. The includes the web front-end and queries from the API.
- G-_event_ pages are not made public. The result of the F2F discussion on 2021/09/15 seemed to indicate that it should remain that way.
- _Superevent_ properties (such as FAR) are inherited from the superevent's preferred event. For reference: a superevent's preferred event is a one-to-one relationship with an event in the database. See here: (https://git.ligo.org/lscsoft/gracedb/-/blob/master/gracedb/superevents/models.py#L92). As such, when a superevent defines its FAR is just a relationship with its preferred event, for example: https://git.ligo.org/lscsoft/gracedb/-/blob/master/gracedb/superevents/models.py#L431
- Data products, such as skymaps, p_astro and such, are uploaded for a superevent and given a couple of tags, such as `skyloc`, which gives the file its own section on a superevent landing page:
![Screen_Shot_2021-09-15_at_12.57.48_PM](/uploads/b6001318e20cb5d5f97973b5a40b632e/Screen_Shot_2021-09-15_at_12.57.48_PM.png)
- Adding a `public` tag will, understandably, make that file (log message) public by having the Django template generator filter based on that public tag (example: https://git.ligo.org/lscsoft/gracedb/-/blob/master/gracedb/templates/superevents/preferred_event_info_table_public.html)
- Similarly, there is a filter of the `public` tag, as well as an authentication check that takes place that selectively returns information via API calls.
- A superevent is a super-set of G-events. This is defined by a ForeignKey database relation (here: https://git.ligo.org/lscsoft/gracedb/-/blob/master/gracedb/events/models.py#L189). This relationship can be created or destroyed by `superevent_manager`s. There's no internal logic deciding this relationship.
Okay. So that's how it works right now. What I propose to _guide the discussion_ is this:
1. What information or products do you want from what events to be made public? Are these event properties, such as FAR and SNR, are there skymaps or other data products?
2. Are these G-event properties coming from G-events are are not already part of a superevent's event relationship? In other words, outside events that are not part of a superevent's event list? If the superevent and event are already linked, then from a technical standpoint, the superevent's landing page and API call can return the information to the public. This is a policy limitation, not a technical limitation. I do not dictate policy.
3. For data products such as skymaps, omega scans, and whatnot, the files are attached to log message objects in the database. Currently, the log message objects are linked via a one-to-one relationship in the database to either a superevent or a g-event.
Elaborating on the last point: concerning data products and files. What I propose from a technical standpoint would be expanding the log-message (and by extension, file product) relationship to include a many-to-many relationship. What this would mean is, a log message and file would be created for a g-event. That's relationship number one. A superevent manager process would determine if that product should be displayed on the superevent page. A new log message is created for the superevent, and that log message would have a linked relationship with the g-event's log message. The set of tags that are usually applied to a superevent's log message (`skyloc`, `public`, etc) are applied to the inherited log message, then boom, it's public.
I think this approach is a way to start and guide the discussion. I believe it has the advantage of:
1. Allowing superevent managers to selectively choose what information and what products are inherited from what g-events.
2. The mechanism for making data products public is unchanged.
3. Adding data products to a superevent (not just public products) is reduced to one API call instead of the convoluted data-transfer bonanza that took place in O3. This is analogous to the "server-side copy" that was discussed in O3b but never brought to fruition.
4. The existing superevent pages, log messages, public views, and event relationships will remain unchanged. Unless a superevent manager changes them.
I see this as a sound technical approach, but I am open to other suggestions. From a policy standpoint, it is up to @erik-katsavounidis and @shaon.ghosh to determine what information from what events and at what time should be linked to a superevent.O4 CBC Improvementshttps://git.ligo.org/computing/gracedb/server/-/issues/205Reading a specified number of bytes from the beginning of a streamed file ret...2021-08-11T17:05:20ZLeo P. SingerReading a specified number of bytes from the beginning of a streamed file returns fewer bytes than expectedWhen streaming a file from GraceDB, calls to `fileobj.read(n)` return fewer than `n` bytes. For example, this script:
```python
#!/usr/bin/env python
from ligo.gracedb.rest import GraceDb
client = GraceDb(fail_if_noauth=True)
for i in r...When streaming a file from GraceDB, calls to `fileobj.read(n)` return fewer than `n` bytes. For example, this script:
```python
#!/usr/bin/env python
from ligo.gracedb.rest import GraceDb
client = GraceDb(fail_if_noauth=True)
for i in range(1, 32):
fileobj = client.files('G330564', 'psd.xml.gz')
magic = fileobj.read(i)
print('requested', i, 'got', len(magic))
```
produces the following output:
```
requested 1 got 0
requested 2 got 0
requested 3 got 0
requested 4 got 0
requested 5 got 0
requested 6 got 0
requested 7 got 0
requested 8 got 0
requested 9 got 0
requested 10 got 0
requested 11 got 0
requested 12 got 0
requested 13 got 0
requested 14 got 0
requested 15 got 0
requested 16 got 1
requested 17 got 2
requested 18 got 3
requested 19 got 4
requested 20 got 5
requested 21 got 6
requested 22 got 7
requested 23 got 8
requested 24 got 9
requested 25 got 10
requested 26 got 11
requested 27 got 12
requested 28 got 13
requested 29 got 14
requested 30 got 15
requested 31 got 16
```
I have reproduced this with a variety of versions of gracedb-client and Python and on both macOS and the LIGO-Caltech cluster, which leads me to think that it is due to a server-side change.
The minimum value of `n` for which output starts seems to depend on the file extension: .xml, .fits, and .png files have problems, whereas .log and .json files start producing output right away. @alexander.pace suggests that this may mean that it has to do with MIME type handling.https://git.ligo.org/computing/gracedb/server/-/issues/204Uploading results of targeted GRB/FRB followup searches2023-07-31T15:01:40ZTito Dal CantonUploading results of targeted GRB/FRB followup searchesIn at least two occasions, people have recently requested PyGRB candidates to be uploaded to GraceDB for detchar and PE followup. One difficulty with this is that PyGRB, being a targeted followup search of an existing transient, reports ...In at least two occasions, people have recently requested PyGRB candidates to be uploaded to GraceDB for detchar and PE followup. One difficulty with this is that PyGRB, being a targeted followup search of an existing transient, reports a p-value (false-alarm probability) associated with data around that particular transient, instead of a false-alarm rate as commonly understood in GraceDB land. PyGRB is also a coherent search, which may create some more impedance mismatch in terms of LIGOLW tables. A similar issue would also arise for any X-pipeline candidate (also from targeted GRB/FRB followup searches), although we have not had any particularly interesting X-pipeline candidates yet.
@alexander.pace suggested opening this issue, but I am not entirely sure if this is a PyGRB/X-pipeline problem, or a GraceDB problem, or maybe more of a schema problem. If we had an interesting continuous-wave or stochastic candidate, for example, would people want to see that in GraceDB as well, and what would the solution be?
Tagging @derek.davis, @francesco-pannarale and @ian-harry.https://git.ligo.org/computing/gracedb/server/-/issues/203Update signoff button is very difficult to click, mouse focus blocked by text2022-02-06T00:22:25ZLeo P. SingerUpdate signoff button is very difficult to click, mouse focus blocked by textIt is very difficult to click the "Update signoff" button because the text seems to steal the mouse focus away from the button itself. Only parts of the button that do not contain text are clickable. See attached screen recording.
![Scr...It is very difficult to click the "Update signoff" button because the text seems to steal the mouse focus away from the button itself. Only parts of the button that do not contain text are clickable. See attached screen recording.
![Screen_Recording_2021-03-01_at_15.24.10](/uploads/88c526533f6c9db39390f5f93de7f648/Screen_Recording_2021-03-01_at_15.24.10.mov)https://git.ligo.org/computing/gracedb/server/-/issues/202Add an obvious way to download images shown in light boxes2022-03-22T18:09:19ZLeo P. SingerAdd an obvious way to download images shown in light boxesThere is no obvious way to download images shown in light boxes. However the images are being displayed, the right-click menu does not give an option to save the image.
Here is a screenshot from Chrome:
![Screen_Shot_2021-01-13_at_08.5...There is no obvious way to download images shown in light boxes. However the images are being displayed, the right-click menu does not give an option to save the image.
Here is a screenshot from Chrome:
![Screen_Shot_2021-01-13_at_08.57.58](/uploads/75a2dc510d8670a8d6d64ef48b49927e/Screen_Shot_2021-01-13_at_08.57.58.png)https://git.ligo.org/computing/gracedb/server/-/issues/201Update O3 public alerts page to point to published catalog2020-11-23T16:55:28ZJonah KannerUpdate O3 public alerts page to point to published catalog@alexander.pace
Here's a suggestion from Beverly Berger to add a pointer to GWTC-2 on the O3 public alerts page.
-jonah
Hi, Jonah.
I had a thought about how to add information on the final resolution of alert triggers to https://grac...@alexander.pace
Here's a suggestion from Beverly Berger to add a pointer to GWTC-2 on the O3 public alerts page.
-jonah
Hi, Jonah.
I had a thought about how to add information on the final resolution of alert triggers to https://gracedb.ligo.org/superevents/public/O3/. I think it would be sufficient to say something like see (relevant table of events in GWOSC) and (section in the catalog paper where the reasons for the final set of events are given).
Beverly