Reading a specified number of bytes from the beginning of a streamed file returns fewer bytes than expected
When streaming a file from GraceDB, calls to fileobj.read(n)
return fewer than n
bytes. For example, this script:
#!/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.