GraceDB Server issueshttps://git.ligo.org/computing/gracedb/server/-/issues2024-03-21T00:12:39Zhttps://git.ligo.org/computing/gracedb/server/-/issues/343Missing `else` clause in `check_and_serve_file`2024-03-21T00:12:39ZDaniel WysockiMissing `else` clause in `check_and_serve_file`[Sentry reported an error](https://ligo-caltech.sentry.io/issues/5081076463/?alert_rule_id=710526&alert_timestamp=1710797810690&alert_type=email&environment=test&notification_uuid=b5bfedba-abe7-4d31-b25f-280fa8935ba7&project=1456379&refe...[Sentry reported an error](https://ligo-caltech.sentry.io/issues/5081076463/?alert_rule_id=710526&alert_timestamp=1710797810690&alert_type=email&environment=test¬ification_uuid=b5bfedba-abe7-4d31-b25f-280fa8935ba7&project=1456379&referrer=alert_email) in [`core.http.check_and_serve_file`](https://git.ligo.org/computing/gracedb/server/-/blob/bebc24500045d00fc74ba56818bd9b34e184c310/gracedb/core/http.py#L62). The issue is that there's no `else` clause, and `response` is undefined. I don't know of a way to get more details behind this _instance_ of the error, however, there's only one possibility I see triggering this: `file_path` refers to a directory.
This would be solved by adding a simple `else` clause to catch all possible remaining errors, though we should probably identify exactly what happened here and see if it needs special treatment. Why did a user try accessing a file that was actually directory, assuming my assessment is correct?Daniel WysockiDaniel Wysockihttps://git.ligo.org/computing/gracedb/server/-/issues/285Occasional shuffling of containers in swarm deployment.2024-03-13T21:18:40ZAlexander PaceOccasional shuffling of containers in swarm deployment.Occasionally docker swarm will shuffle which containers are running on which nodes, and I'm still trying to figure out why. So for example, earlier this morning:
![Screen_Shot_2023-04-21_at_11.36.02_AM](/uploads/d4e8b473b9d61ccbcad2887...Occasionally docker swarm will shuffle which containers are running on which nodes, and I'm still trying to figure out why. So for example, earlier this morning:
![Screen_Shot_2023-04-21_at_11.36.02_AM](/uploads/d4e8b473b9d61ccbcad288725ff4b33a/Screen_Shot_2023-04-21_at_11.36.02_AM.png)
The containers were running stably on nodes a, b, c, but then the gracedb container on b switched to a different node. Looking at the logs for gracedb/traefik/haproxy showed these warnings coming from HAproxy (`webgateway_dockersocket`):
```
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.3.zl5suk39kwwg50fty1u6f3vyt: Stopping backend dockerbackend in 0 ms.
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.3.zl5suk39kwwg50fty1u6f3vyt: Stopping frontend dockerfrontend in 0 ms.
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.3.zl5suk39kwwg50fty1u6f3vyt: Proxy dockerbackend stopped (FE: 0 conns, BE: 166378 conns).
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.3.zl5suk39kwwg50fty1u6f3vyt: Proxy dockerfrontend stopped (FE: 23768 conns, BE: 0 conns).
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.1.ntddvqu1j5e3eqms12t8h12d9: [WARNING] 110/144524 (1) : Exiting Master process...
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.3.zl5suk39kwwg50fty1u6f3vyt: [WARNING] 110/144524 (1) : Exiting Master process...
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.3.zl5suk39kwwg50fty1u6f3vyt: [WARNING] 110/144524 (7) : Stopping backend dockerbackend in 0 ms.
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.3.zl5suk39kwwg50fty1u6f3vyt: [WARNING] 110/144524 (7) : Stopping frontend dockerfrontend in 0 ms.
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.3.zl5suk39kwwg50fty1u6f3vyt: [WARNING] 110/144524 (7) : Stopping frontend GLOBAL in 0 ms.
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.3.zl5suk39kwwg50fty1u6f3vyt: [WARNING] 110/144524 (7) : Proxy dockerbackend stopped (FE: 0 conns, BE: 166378 conns).
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.3.zl5suk39kwwg50fty1u6f3vyt: [WARNING] 110/144524 (7) : Proxy dockerfrontend stopped (FE: 23768 conns, BE: 0 conns).
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.3.zl5suk39kwwg50fty1u6f3vyt: [WARNING] 110/144524 (7) : Proxy GLOBAL stopped (FE: 0 conns, BE: 0 conns).
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.1.ntddvqu1j5e3eqms12t8h12d9: [WARNING] 110/144524 (7) : Stopping backend dockerbackend in 0 ms.
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.1.ntddvqu1j5e3eqms12t8h12d9: [WARNING] 110/144524 (7) : Stopping frontend dockerfrontend in 0 ms.
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.1.ntddvqu1j5e3eqms12t8h12d9: Stopping backend dockerbackend in 0 ms.
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.1.ntddvqu1j5e3eqms12t8h12d9: Stopping frontend dockerfrontend in 0 ms.
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.1.ntddvqu1j5e3eqms12t8h12d9: Proxy dockerbackend stopped (FE: 0 conns, BE: 63211 conns).
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.1.ntddvqu1j5e3eqms12t8h12d9: Proxy dockerfrontend stopped (FE: 9029 conns, BE: 0 conns).
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.1.ntddvqu1j5e3eqms12t8h12d9: [WARNING] 110/144524 (7) : Stopping frontend GLOBAL in 0 ms.
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.1.ntddvqu1j5e3eqms12t8h12d9: [WARNING] 110/144524 (7) : Proxy dockerbackend stopped (FE: 0 conns, BE: 63211 conns).
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.1.ntddvqu1j5e3eqms12t8h12d9: [WARNING] 110/144524 (7) : Proxy dockerfrontend stopped (FE: 9029 conns, BE: 0 conns).
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.1.ntddvqu1j5e3eqms12t8h12d9: [WARNING] 110/144524 (7) : Proxy GLOBAL stopped (FE: 0 conns, BE: 0 conns).
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.3.zl5suk39kwwg50fty1u6f3vyt: [ALERT] 110/144524 (1) : Current worker #1 (7) exited with code 0 (Exit)
Apr 21 14:45:24 gracedb_docker_webgateway_dockersocket.1.ntddvqu1j5e3eqms12t8h12d9: [ALERT] 110/144524 (1) : Current worker #1 (7) exited with code 0 (Exit)
```
followed in the same log file as the errors from traefik (`webgateway_webgateway`):
```
Apr 21 14:45:24 gracedb_docker_webgateway_webgateway.2.rn0rimzkaijqp324b90r9ts09: 131.215.113.226 - - [21/Apr/2023:14:45:24 +0000] "GET /api/events/G989764/log/ HTTP/1.1" 200 1082 "-" "-" 621950 "gracedb@docker" "http://10.0.0.47:80" 95ms
Apr 21 14:45:24 gracedb_docker_webgateway_webgateway.2.rn0rimzkaijqp324b90r9ts09: time="2023-04-21T14:45:24Z" level=error msg="accept tcp [::]:443: use of closed network connection" entryPointName=websecure
Apr 21 14:45:24 gracedb_docker_webgateway_webgateway.2.rn0rimzkaijqp324b90r9ts09: time="2023-04-21T14:45:24Z" level=error msg="accept tcp [::]:80: use of closed network connection" entryPointName=web
Apr 21 14:45:24 gracedb_docker_webgateway_webgateway.2.rn0rimzkaijqp324b90r9ts09: time="2023-04-21T14:45:24Z" level=error msg="Error while starting server: http: Server closed" entryPointName=web
Apr 21 14:45:24 gracedb_docker_webgateway_webgateway.2.rn0rimzkaijqp324b90r9ts09: time="2023-04-21T14:45:24Z" level=error msg="Error while starting server: http: Server closed" entryPointName=websecure
Apr 21 14:45:24 gracedb_docker_webgateway_webgateway.2.rn0rimzkaijqp324b90r9ts09: time="2023-04-21T14:45:24Z" level=error msg="Error while starting server: http: Server closed" entryPointName=web
Apr 21 14:45:24 gracedb_docker_webgateway_webgateway.2.rn0rimzkaijqp324b90r9ts09: time="2023-04-21T14:45:24Z" level=error msg="close tcp [::]:80: use of closed network connection" entryPointName=web
Apr 21 14:45:24 gracedb_docker_webgateway_webgateway.2.rn0rimzkaijqp324b90r9ts09: time="2023-04-21T14:45:24Z" level=error msg="Error while starting server: http: Server closed" entryPointName=websecure
```
on the gracedb side, there were a string of errors coming from kafka:
```
Apr 21 14:45:24 gracedb-swarm-playground-us-west-2b-docker-mgr-01 gracedb_docker_gracedb_gracedb.3.rn3qo0xic2k63c3j2oflftrbz: 2023-04-21 14:45:24,354 INFO stopped: shibd (exit status 0)
Apr 21 14:45:24 gracedb-swarm-playground-us-west-2b-docker-mgr-01 gracedb_docker_gracedb_gracedb.3.rn3qo0xic2k63c3j2oflftrbz: internal kafka error: KafkaError{code=_TRANSPORT,val=-195,str="sasl_ssl://kb-2.prod.hop.scimma.org:9092/2: Disconnected (after 1245141ms in state UP)"}
Apr 21 14:45:24 gracedb-swarm-playground-us-west-2b-docker-mgr-01 gracedb_docker_gracedb_gracedb.3.rn3qo0xic2k63c3j2oflftrbz: internal kafka error: KafkaError{code=_TRANSPORT,val=-195,str="sasl_ssl://kb-2.prod.hop.scimma.org:9092/2: Disconnected (after 710755ms in state UP, 1 identical error(s) suppressed)"}
Apr 21 14:45:24 gracedb-swarm-playground-us-west-2b-docker-mgr-01 gracedb_docker_gracedb_gracedb.3.rn3qo0xic2k63c3j2oflftrbz: internal kafka error: KafkaError{code=_TRANSPORT,val=-195,str="sasl_ssl://kb-1.prod.hop.scimma.org:9092/1: Disconnected (after 710652ms in state UP)"}
Apr 21 14:45:24 gracedb-swarm-playground-us-west-2b-docker-mgr-01 gracedb_docker_gracedb_gracedb.3.rn3qo0xic2k63c3j2oflftrbz: internal kafka error: KafkaError{code=_TRANSPORT,val=-195,str="sasl_ssl://kb-1.prod.hop.scimma.org:9092/1: Disconnected (after 11863073ms in state UP, 1 identical error(s) suppressed)"}
Apr 21 14:45:24 gracedb-swarm-playground-us-west-2b-docker-mgr-01 gracedb_docker_gracedb_gracedb.3.rn3qo0xic2k63c3j2oflftrbz: internal kafka error: KafkaError{code=_TRANSPORT,val=-195,str="sasl_ssl://kb-0.prod.hop.scimma.org:9092/0: Disconnected (after 22878079ms in state UP)"}
Apr 21 14:45:24 gracedb-swarm-playground-us-west-2b-docker-mgr-01 gracedb_docker_gracedb_gracedb.3.rn3qo0xic2k63c3j2oflftrbz: internal kafka error: KafkaError{code=_TRANSPORT,val=-195,str="sasl_ssl://kb-1.prod.hop.scimma.org:9092/1: Disconnected (after 9059107ms in state UP, 1 identical error(s) suppressed)"}
Apr 21 14:45:24 gracedb-swarm-playground-us-west-2b-docker-mgr-01 gracedb_docker_gracedb_gracedb.3.rn3qo0xic2k63c3j2oflftrbz: internal kafka error: KafkaError{code=_TRANSPORT,val=-195,str="sasl_ssl://kb-2.prod.hop.scimma.org:9092/2: Disconnected (after 22094640ms in state UP, 1 identical error(s) suppressed)"}
```
But, given that they're all in the same second, it's hard to tell what caused what. If there's any saving grace, the service rolled over to the other nodes automatically... but users connected to node b probably got disconnection errors from the client.
**To recover:**
trigger the services to scale down to two nodes:
```
docker service scale webgateway_webgateway=2 webgateway_dockersocket=2 gracedb_memcached=2 gracedb_gracedb=2
```
then back up to three:
```
docker service scale webgateway_webgateway=3 webgateway_dockersocket=3 gracedb_memcached=3 gracedb_gracedb=3
```O4 Debugging and Improvementshttps://git.ligo.org/computing/gracedb/server/-/issues/247Different information in pipeline_preferred_events dictionary2024-03-13T21:17:01ZCody MessickDifferent information in pipeline_preferred_events dictionaryWe need more information in the `pipeline_preferred_events` dictionary, specifically the SNR from each ifo for CBC events. What would make our life in gwcelery easiest is if you could add the `extra_attributes` field that's populated in ...We need more information in the `pipeline_preferred_events` dictionary, specifically the SNR from each ifo for CBC events. What would make our life in gwcelery easiest is if you could add the `extra_attributes` field that's populated in the `preferred_event_data` field for each preferred pipeline event, that way we could just reuse the same code path when picking pipeline preferred events as we do when picking globally preferred events.
I also don't think we need the `likelihood` field, as not all pipelines use likelihoods.Critical Path O4 Developmenthttps://git.ligo.org/computing/gracedb/server/-/issues/258Server Error: ParseResults([ParseResults([13, 57], {})], {'miltime': [13, 57]})2024-03-13T21:11:48ZAlexander PaceServer Error: ParseResults([ParseResults([13, 57], {})], {'miltime': [13, 57]})A few of these popped up when a user was trying to make a superevent query:
```
Internal Server Error: /api/superevents/
KeyError at /api/superevents/
ParseResults([ParseResults([13, 57], {})], {'miltime': [13, 57]})
Request Method: G...A few of these popped up when a user was trying to make a superevent query:
```
Internal Server Error: /api/superevents/
KeyError at /api/superevents/
ParseResults([ParseResults([13, 57], {})], {'miltime': [13, 57]})
Request Method: GET
Request URL: http://gracedb-playground.ligo.org/api/superevents/?query=created%3A+1357152000.000000+..+1360608000.000000
Django Version: 3.2.16
Python Executable: /usr/bin/python3
Python Version: 3.7.3
Python Path: ['/usr/local/bin', '/usr/local/lib/python3.7/dist-packages', '/app/gracedb_project', '/usr/lib/python37.zip', '/usr/lib/python3.7', '/usr/lib/python3.7/lib-dynload', '/usr/lib/python3/dist-packages', '/app/gracedb_project', '/app/gracedb_project/gracedb', '/usr/local/lib/python3.7/dist-packages/IPython/extensions']
Server time: Tue, 28 Feb 2023 19:13:49 +0000
Installed Applications:
[...]
Traceback (most recent call last):
File "/usr/local/lib/python3.7/dist-packages/django/core/handlers/exception.py", line 47, in inner
response = get_response(request)
File "/usr/local/lib/python3.7/dist-packages/django/core/handlers/base.py", line 181, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/usr/local/lib/python3.7/dist-packages/django/views/decorators/cache.py", line 44, in _wrapped_view_func
response = view_func(request, *args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
return view_func(*args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/rest_framework/viewsets.py", line 125, in view
return self.dispatch(request, *args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/rest_framework/views.py", line 509, in dispatch
response = self.handle_exception(exc)
File "/usr/local/lib/python3.7/dist-packages/rest_framework/views.py", line 469, in handle_exception
self.raise_uncaught_exception(exc)
File "/usr/local/lib/python3.7/dist-packages/rest_framework/views.py", line 480, in raise_uncaught_exception
raise exc
File "/usr/local/lib/python3.7/dist-packages/rest_framework/views.py", line 506, in dispatch
response = handler(request, *args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/rest_framework/mixins.py", line 38, in list
queryset = self.filter_queryset(self.get_queryset())
File "/usr/local/lib/python3.7/dist-packages/rest_framework/generics.py", line 150, in filter_queryset
queryset = backend().filter_queryset(self.request, queryset, self)
File "/app/gracedb_project/gracedb/api/v1/superevents/filters.py", line 38, in filter_queryset
filter_params = parseSupereventQuery(query)
File "/app/gracedb_project/gracedb/search/query/superevents.py", line 293, in parseSupereventQuery
matches = (stringStart + OneOrMore(q) + stringEnd).parseString(s).asList()
File "/usr/local/lib/python3.7/dist-packages/pyparsing/core.py", line 1131, in parse_string
loc, tokens = self._parse(instring, 0)
File "/usr/local/lib/python3.7/dist-packages/pyparsing/core.py", line 817, in _parseNoCache
loc, tokens = self.parseImpl(instring, pre_loc, doActions)
File "/usr/local/lib/python3.7/dist-packages/pyparsing/core.py", line 3886, in parseImpl
loc, exprtokens = e._parse(instring, loc, doActions)
File "/usr/local/lib/python3.7/dist-packages/pyparsing/core.py", line 817, in _parseNoCache
loc, tokens = self.parseImpl(instring, pre_loc, doActions)
File "/usr/local/lib/python3.7/dist-packages/pyparsing/core.py", line 4790, in parseImpl
loc, tokens = self_expr_parse(instring, loc, doActions)
File "/usr/local/lib/python3.7/dist-packages/pyparsing/core.py", line 817, in _parseNoCache
loc, tokens = self.parseImpl(instring, pre_loc, doActions)
File "/usr/local/lib/python3.7/dist-packages/pyparsing/core.py", line 3999, in parseImpl
loc2, toks = expr1._parse(instring, loc, doActions)
File "/usr/local/lib/python3.7/dist-packages/pyparsing/core.py", line 817, in _parseNoCache
loc, tokens = self.parseImpl(instring, pre_loc, doActions)
File "/usr/local/lib/python3.7/dist-packages/pyparsing/core.py", line 3886, in parseImpl
loc, exprtokens = e._parse(instring, loc, doActions)
File "/usr/local/lib/python3.7/dist-packages/pyparsing/core.py", line 817, in _parseNoCache
loc, tokens = self.parseImpl(instring, pre_loc, doActions)
File "/usr/local/lib/python3.7/dist-packages/pyparsing/core.py", line 3999, in parseImpl
loc2, toks = expr1._parse(instring, loc, doActions)
File "/usr/local/lib/python3.7/dist-packages/pyparsing/core.py", line 817, in _parseNoCache
loc, tokens = self.parseImpl(instring, pre_loc, doActions)
File "/usr/local/lib/python3.7/dist-packages/pyparsing/core.py", line 4117, in parseImpl
doActions,
File "/usr/local/lib/python3.7/dist-packages/pyparsing/core.py", line 856, in _parseNoCache
tokens = fn(instring, tokens_start, ret_tokens)
File "/usr/local/lib/python3.7/dist-packages/pyparsing/core.py", line 291, in wrapper
ret = func(*args[limit:])
File "/app/gracedb_project/gracedb/events/nltime.py", line 82, in convertToAbsTime
}[timeOfDayStr]
Exception Type: KeyError at /api/superevents/
Exception Value: ParseResults([ParseResults([13, 57], {})], {'miltime': [13, 57]})
Request information:
USER: ryan.magee@ligo.org
GET:
query = 'created: 1357152000.000000 .. 1360608000.000000'
POST: No POST data
FILES: No FILES data
```
might have something to do with the number of decimal points...? not sure yetO4 Debugging and Improvementshttps://git.ligo.org/computing/gracedb/server/-/issues/341only send igwn-alerts to the {group}_{pipeline} topic2024-03-13T20:29:24ZAlexander Paceonly send igwn-alerts to the {group}_{pipeline} topicHistorically `igwn-alert` and `LVAlert` sends out g-event and e-event alerts to topics with the `{group}_{pipeline}` and `{group}_{pipeline}_{search}` schema. As more pipelines and searches are added, topic management is becoming a pain ...Historically `igwn-alert` and `LVAlert` sends out g-event and e-event alerts to topics with the `{group}_{pipeline}` and `{group}_{pipeline}_{search}` schema. As more pipelines and searches are added, topic management is becoming a pain across all the GraceDB tiers, especially with the lack of a scriptable API to interact with SCIMMA.
I'm proposing to change the way GraceDB issues alerts to only send to `{group}_{pipeline}` topics and have users filter on search, if need be. It would have the benefit of simplifying topic management, and also save some milliseconds in dispatching alerts. The alert contents would remain the same. Superevent topics would be unaffected by this change.
Putting out feelers to `igwn-alert` stakeholders... @deep.chatterjee @cody.messick @nicolas.arnaud @rebecca.ewing would that break your listening processes, if so, would adding an extra filter based on the search in the alert content be too much of a technical burden?O4bAlexander PaceAlexander Pacehttps://git.ligo.org/computing/gracedb/server/-/issues/338Ingest GCN VOEvents from SVOM2024-02-23T20:30:01ZBrandon PiotrzkowskiIngest GCN VOEvents from SVOMRequested by @rachel.hamburg, we want to start ingesting VOEvents from SVOM as another `GRB` search.
Here's an example of a notice:
[sb23041100_eclairs-wakeup_2.xml](/uploads/ad0d71686252e09b6e623e1a11eaf0e2/sb23041100_eclairs-wakeup_2...Requested by @rachel.hamburg, we want to start ingesting VOEvents from SVOM as another `GRB` search.
Here's an example of a notice:
[sb23041100_eclairs-wakeup_2.xml](/uploads/ad0d71686252e09b6e623e1a11eaf0e2/sb23041100_eclairs-wakeup_2.xml)
This will require the following changes
- [ ] Add `pipeline='SVOM'` as mentioned in https://git.ligo.org/computing/gracedb/server/-/issues/255
- [ ] Add `SVOM` external events to IGWN alert
- [ ] Modify [translator](https://git.ligo.org/computing/gracedb/server/-/blob/master/gracedb/events/translator.py) to ingest the particular notice values, such as adding `"Burst_Id"` to get the ID and `"Exposure"` to get the duration.O4bhttps://git.ligo.org/computing/gracedb/server/-/issues/340Add support for validating read access against multiple token issuers2024-02-20T15:51:31ZJosh WillisAdd support for validating read access against multiple token issuersCurrently a single gracedb instance can only accept tokens from one-and-only-one token issuer. This will need to change to support the HTCondor 'local issuer' that we will be rolling out as an alternative to vault-managed scitokens.Currently a single gracedb instance can only accept tokens from one-and-only-one token issuer. This will need to change to support the HTCondor 'local issuer' that we will be rolling out as an alternative to vault-managed scitokens.https://git.ligo.org/computing/gracedb/server/-/issues/20Flip between images that have the same tag2024-01-30T16:51:24ZTanner PrestegardFlip between images that have the same tagStarted in 2014. Copied from redmine (https://bugs.ligo.org/redmine/issues/1156)
> Hi Branson,
>
> I have two feature requests for the lightboxes that are displayed in GraceDb for uploaded images. See <https://gracedb.ligo.org/events/...Started in 2014. Copied from redmine (https://bugs.ligo.org/redmine/issues/1156)
> Hi Branson,
>
> I have two feature requests for the lightboxes that are displayed in GraceDb for uploaded images. See <https://gracedb.ligo.org/events/view/T81925>.
>
> The first request is for the pop-up to have an opaque white background, to improve readability. The transparent backgrounds make it difficult to read the text on the png sky maps.
>
> The second request is to add the ability to flip between images that belong to the same tag or group. This event has two sky maps, one from BAYESTAR and one from the full MCMC. It would be very handy if it was possible to flip between them when inside the popup.
>
> Thank you!
> Leohttps://git.ligo.org/computing/gracedb/server/-/issues/298Add new BBH search to GraceDB Playground2024-01-30T16:40:46ZWilliam BenoitAdd new BBH search to GraceDB PlaygroundOur group would like our binary black hole search pipeline, `aframe`, to be added to GraceDB Playground. An example output file is attached.
[event_1368221446.json](/uploads/850dede670d9e1bff55a637616c67b65/event_1368221446.json)
As `a...Our group would like our binary black hole search pipeline, `aframe`, to be added to GraceDB Playground. An example output file is attached.
[event_1368221446.json](/uploads/850dede670d9e1bff55a637616c67b65/event_1368221446.json)
As `aframe` is a machine learning-based pipeline that performs binary classification of the strain data, we do not provide any parameters associated with the signal.
We have a simple online implementation prepared, and are currently developing the complete workflow, which will include automatically re-training and evaluating the network. Please let me know if you need further information.O4 Debugging and Improvementshttps://git.ligo.org/computing/gracedb/server/-/issues/336service dies with out-of-date gpstime package2024-01-10T12:05:13ZAlexander Paceservice dies with out-of-date gpstime packageI started a rolling restart of gracedb-playground and when it came back online, it 503'ed with the following error:
```
Traceback (most recent call last):
File "/app/gracedb_project/manage.py", line 44, in <module>
execute_from_co...I started a rolling restart of gracedb-playground and when it came back online, it 503'ed with the following error:
```
Traceback (most recent call last):
File "/app/gracedb_project/manage.py", line 44, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/lib/python3.9/dist-packages/django/core/management/__init__.py", line 419, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python3.9/dist-packages/django/core/management/__init__.py", line 395, in execute
django.setup()
File "/usr/local/lib/python3.9/dist-packages/django/__init__.py", line 24, in setup
apps.populate(settings.INSTALLED_APPS)
File "/usr/local/lib/python3.9/dist-packages/django/apps/registry.py", line 114, in populate
app_config.import_models()
File "/usr/local/lib/python3.9/dist-packages/django/apps/config.py", line 301, in import_models
self.models_module = import_module(models_module_name)
File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 790, in exec_module
File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
File "/app/gracedb_project/gracedb/alerts/models.py", line 19, in <module>
from .phone import get_twilio_from
File "/app/gracedb_project/gracedb/alerts/phone.py", line 12, in <module>
from events.permission_utils import is_external
File "/app/gracedb_project/gracedb/events/permission_utils.py", line 9, in <module>
from .models import Event
File "/app/gracedb_project/gracedb/events/models.py", line 31, in <module>
from gpstime import gpstime
File "/usr/local/lib/python3.9/dist-packages/gpstime/__init__.py", line 41, in <module>
from .leaps import LEAPDATA
File "/usr/local/lib/python3.9/dist-packages/gpstime/leaps.py", line 187, in <module>
LEAPDATA = LeapData()
File "/usr/local/lib/python3.9/dist-packages/gpstime/leaps.py", line 126, in __init__
self._load(fetch_ietf_leapfile, LEAPFILE_IETF_URL)
File "/usr/local/lib/python3.9/dist-packages/gpstime/leaps.py", line 136, in _load
raise RuntimeError(f"Error loading leap file {path}: {str(e)}")
RuntimeError: Error loading leap file https://www.ietf.org/timezones/data/leap-seconds.list: 404 Client Error: Not Found for url: https://www.ietf.org/timezones/data/leap-seconds.list
```
uhhhh does it not seem dangerous to anyone else to depend on an external file like that which just breaks the package.
I brought playground down to one container, and manually upgraded `gpstime` (from 0.6.2) to the latest version (0.8.1, https://git.ligo.org/computing/sccb/-/issues/1397) and that fixed it.
What this means is that production is waiting to break if it restarts for any reason. I'm going to upgrade `gpstime`, build new containers and redeploy while the detectors are offline.https://git.ligo.org/computing/gracedb/server/-/issues/267Revamp public alert page for O42023-12-04T15:55:13ZAlexander PaceRevamp public alert page for O4I got an email forwarded to me from leo singer from someone who asked him why the page https://gracedb.ligo.org/superevents/public/O4/ wasn't working... which was a reminder to me that the Public Alerts page needs to be updated ahead of ...I got an email forwarded to me from leo singer from someone who asked him why the page https://gracedb.ligo.org/superevents/public/O4/ wasn't working... which was a reminder to me that the Public Alerts page needs to be updated ahead of O4.
This is what I'm thinking: `/superevents/public/O3/` (the current page) and `/superevents/public/O4/` will both forward to a single page, `/superevents/public/`.
On that page, there's two tables that are identical in content to the current public table, except one is for O4 (at the top) and one is for O3 (underneath). The HTML for the table is already in place so it doesn't need to be duplicated, but the querysets being fed into the table need to be different.
So what needs to happen is:
- [ ] [urls.py](https://git.ligo.org/computing/gracedb/server/-/blob/8f85c42dcb699248e382397406eb5f6992870c3e/gracedb/superevents/urls.py#L38-40) should be updated to forward URLs to the new page at `/superevents/public/`
- [ ] [views.py](https://git.ligo.org/computing/gracedb/server/-/blob/8f85c42dcb699248e382397406eb5f6992870c3e/gracedb/superevents/views.py#L183-257) should be modified so that the `context` dictionary has two keys: (`O3:`, `O4:`) with the table contents as their values. Basically that means the `self.object_list` (which is a queryset of public superevents) in `get_context_data` needs to be filtered again for each observation run. Fortunately there is already the `RUN_MAP` dictionary ([here](https://git.ligo.org/computing/gracedb/server/-/blob/8f85c42dcb699248e382397406eb5f6992870c3e/gracedb/search/constants.py#L19-55)) that has gpstimes to filter `t_0` on. So, one filter for O3, and then defining a new variable like `O4_START` and then filtering from `O4_START` to now. There may be a better way of doing that. Side question: if someone tries to load the page before O4, and in this scenario, `O4_START` > now... is that going to break the query? Maybe? Then just catch the error with an `except:` and then return an empty dict, easy peasy.
- [ ] [public_alerts.html](https://git.ligo.org/computing/gracedb/server/-/blob/8f85c42dcb699248e382397406eb5f6992870c3e/gracedb/templates/superevents/public_alerts.html) should be modified to accept the new `context` dictionary and render two tables. The table format should be cleaned up too to make it more consistent with the rest of the site, but that's largely the discretion of the dev.
There may be a few other sundry items in there to clean up that I forgot about.Critical Path O4 Developmenthttps://git.ligo.org/computing/gracedb/server/-/issues/331Unable to receive notifications2023-10-23T01:37:15ZElenna CapoteUnable to receive notificationsI am signed up to receive email alerts from graceDB, and it worked reliably well throughout the summer. Now, for the path month or so, I haven't received any alerts, although I know we are detecting many events.
I am signed up for alerts...I am signed up to receive email alerts from graceDB, and it worked reliably well throughout the summer. Now, for the path month or so, I haven't received any alerts, although I know we are detecting many events.
I am signed up for alerts tagged as "ADVREQ", which is what I was told was correct. I also tested my notifications and I receive the test email fine. The email address is my gmail address. I confirmed the test email arrives in my inbox, and I check my spam filter when event alerts go out and I have not mistakenly received the email to my spam.https://git.ligo.org/computing/gracedb/server/-/issues/330Queries based on SNR?2023-10-17T02:40:44ZKeita KawabeQueries based on SNR?It seems that [queries based on SNR are not supported](https://gracedb.ligo.org/documentation/queries.html). I learned this when I tried to quickly find [S230814h aka snr>40 event](https://gracedb.ligo.org/superevents/S230814ah/view/), b...It seems that [queries based on SNR are not supported](https://gracedb.ligo.org/documentation/queries.html). I learned this when I tried to quickly find [S230814h aka snr>40 event](https://gracedb.ligo.org/superevents/S230814ah/view/), but I can imagine that this would be useful, even if that's just for satisfying my curiosity ;)Daniel WysockiDaniel Wysockihttps://git.ligo.org/computing/gracedb/server/-/issues/327"Public events" overview must show Bilby skymap graphics not Bilby.multiorder...2023-09-28T19:12:52ZKeita Kawabe"Public events" overview must show Bilby skymap graphics not Bilby.multiorder.fits files["Public Events" overview page](https://gracedb.ligo.org/superevents/public/O4/) usually shows a thumbnail image of the skymap.
When PE update is sent out(??), Bilby.multiorder.fits file is linked instead and it appears to the users as ...["Public Events" overview page](https://gracedb.ligo.org/superevents/public/O4/) usually shows a thumbnail image of the skymap.
When PE update is sent out(??), Bilby.multiorder.fits file is linked instead and it appears to the users as if the link is broken, see attached. This should be changed to Bilby.png,0 etc.
![Screenshot_2023-09-10_at_13.49.53](/uploads/e605a14cfcfb0f2e358bb685874a1c01/Screenshot_2023-09-10_at_13.49.53.png)https://git.ligo.org/computing/gracedb/server/-/issues/325Add S-event ID to the advocate signoff popup windows2023-09-11T02:39:25ZNicolas ArnaudAdd S-event ID to the advocate signoff popup windowsMeaning: replacing the first sentence of the popup messages (three different ones I think)
> You are attempting to create/update/delete an Advocate Sign-Off (...)
by
> You are attempting to create/update/delete an Advocate Sign-Off **...Meaning: replacing the first sentence of the popup messages (three different ones I think)
> You are attempting to create/update/delete an Advocate Sign-Off (...)
by
> You are attempting to create/update/delete an Advocate Sign-Off **for Superevent SYYMMDD<abc>** (...)
That would give advocates one more chance to check they are about to signoff for the right event.https://git.ligo.org/computing/gracedb/server/-/issues/326GraceDB popup before confirming the advocate signoff2023-09-01T00:17:20ZKeita KawabeGraceDB popup before confirming the advocate signoffBefore making/changing/deleting Advocate Signoff, "are you really sure?" type dialog box should be displayed. See the comment of @nicolas.arnaud in https://git.ligo.org/emfollow/followup-advocate-guide/-/issues/91:
> Yesterday we had the...Before making/changing/deleting Advocate Signoff, "are you really sure?" type dialog box should be displayed. See the comment of @nicolas.arnaud in https://git.ligo.org/emfollow/followup-advocate-guide/-/issues/91:
> Yesterday we had the case of a Lv0 shifter who used the advocate signoff interface on the wrong superevent... While what follows won't prevent this from happening again, I would suggest adding to the section https://emfollow.docs.ligo.org/followup-advocate-guide/procedures1.html#sign-off-okay-on superevent (and possibly to https://emfollow.docs.ligo.org/followup-advocate-guide/procedures1.html#sign-off-not-okay-on-superevent as well) the fact that, when pressing the signoff button, the action is not immediate. Instead, a popup window appears with an appropriate message (depending on what the action will be)
> > You are attempting to create an Advocate Sign-Off, which will generate a public alert. Do you wish to continue?
> > You are attempting to update an Advocate Sign-Off. Do you wish to continue?
> > You are attempting to delete an Advocate Sign-Off. Do you wish to continue?
>And, at this stage, the shifter should really pause for a few seconds, review what they are about to do and (only) then press OK or cancel.https://git.ligo.org/computing/gracedb/server/-/issues/315Proposal to enable SNR threshold setting for phone and email alerts.2023-08-30T07:06:12ZTakahiro SawadaProposal to enable SNR threshold setting for phone and email alerts.The GraceDB web page has the function to set FAR threshold for phone and email alerts. It would be helpful to be able to set SNR threshold as well.The GraceDB web page has the function to set FAR threshold for phone and email alerts. It would be helpful to be able to set SNR threshold as well.https://git.ligo.org/computing/gracedb/server/-/issues/321documentation for cwb_r and cwb_s2023-07-28T18:28:52ZAlexander Pacedocumentation for cwb_r and cwb_s@roberto.depietri @marek.szczepanczyk
There is essentially [no documentation](https://git.ligo.org/computing/gracedb/server/-/blob/master/docs/user_docs/source/labels.rst?plain=1#L23-27) for what the `cWB_r` and `cWB_s` actually represe...@roberto.depietri @marek.szczepanczyk
There is essentially [no documentation](https://git.ligo.org/computing/gracedb/server/-/blob/master/docs/user_docs/source/labels.rst?plain=1#L23-27) for what the `cWB_r` and `cWB_s` actually represent.
Could you please provide one concise sentence for each label, so that can go in gracedb's documentation and toolip?https://git.ligo.org/computing/gracedb/server/-/issues/320Phone number not recognised2023-07-19T10:51:36ZDaniela PascucciPhone number not recognisedWhen I submit my mobile number in the contact list I get the error "Not a valid phone number".
I have a Belgian phone number and I use the format "+32*********".
It might be that that the problem is the country code. Just as a check, I ...When I submit my mobile number in the contact list I get the error "Not a valid phone number".
I have a Belgian phone number and I use the format "+32*********".
It might be that that the problem is the country code. Just as a check, I tried to change it from +32 to +33 (keeping the same number) and in that case there was no error.https://git.ligo.org/computing/gracedb/server/-/issues/318Change public page default view to hide insignificant by default2023-07-18T15:49:20ZAlexander PaceChange public page default view to hide insignificant by defaultThe public page absolutely crawls right now because there are too many insignificant events. Changing the caching policy (https://git.ligo.org/computing/gracedb/server/-/merge_requests/150) will help, but I am also going to propose the f...The public page absolutely crawls right now because there are too many insignificant events. Changing the caching policy (https://git.ligo.org/computing/gracedb/server/-/merge_requests/150) will help, but I am also going to propose the following:
1) Keep the wording and table structure the same
2) Hide insignificant events by default
3) Change the backend behavior so that the "show significant events only" button triggers a new database transaction, instead of loading everything at once and then hiding the html elements.
Thoughts on this, @keita.kawabe?