active immutable downloads are shown on Recent Operations instead of Active Operations #1172

New Issue

zooko · 2010-08-12T20:47:42Z

zooko commented

2010-08-12 20:47:42 +00:00

An immutable download is still in-progress, but it appears in Recent Operations instead of Active Operations. By the way, the source code responsible for this may be close to the source code responsible for #1079 (upload of file into dir doesn't appear on Recent Uploads and Downloads).

zooko added the

labels 2010-08-12 20:47:42 +00:00

zooko added this to the undecided milestone 2010-08-12 20:47:42 +00:00

zooko commented

2010-08-12 20:47:59 +00:00

Attachment Tahoe-LAFS - Current Uploads_Downloads.html (2402 bytes) added

**Attachment** Tahoe-LAFS - Current Uploads_Downloads.html (2402 bytes) added

Tahoe-LAFS - Current Uploads_Downloads.html

2.3 KiB

zooko commented

2010-08-14 07:05:58 +00:00

Should we try to fix this for v1.8.0? I would lean toward "yes".

zooko modified the milestone from undecided to 1.8.0

2010-08-14 07:05:58 +00:00

warner commented

2010-08-14 18:30:56 +00:00

The fix for this will go into source:src/allmydata/immutable/downloader/status.py#L244 ish (DownloadStatus.get_active). It currently is a stub that always returns False. That should be replaced by something which, I dunno, probably does the same "look for read_events that have a non-None finishtime" check that get_progress uses, so "active" means "has outstanding read() calls".

The fix for this will go into source:src/allmydata/immutable/downloader/status.py#L244 ish (`DownloadStatus.get_active`). It currently is a stub that always returns `False`. That should be replaced by something which, I dunno, probably does the same "look for read_events that have a non-None `finishtime`" check that `get_progress` uses, so "active" means "has outstanding `read()` calls".

francois commented

2010-08-31 11:08:32 +00:00

Attachment downloader-status-1172.dpatch (2867 bytes) added

**Attachment** downloader-status-1172.dpatch (2867 bytes) added

downloader-status-1172.dpatch

2.8 KiB

francois commented

2010-08-31 11:12:57 +00:00

The attached patch implements what Brian proposed in [comment:79670](/tahoe-lafs/trac-2024-07-25/issues/1172#issuecomment-79670) and add an appropriate test.

The attached patch implements what Brian proposed in [[comment:79670](/tahoe-lafs/trac-2024-07-25/issues/1172#issuecomment-79670)](/tahoe-lafs/trac-2024-07-25/issues/1172#issuecomment-79670) and add an appropriate test.

warner commented

2010-08-31 21:15:23 +00:00

I'm ok with this patch. Be aware that if we land the #1170 patches (specifically 1170-p2.diff) then this one will need to be rewritten, since the download-status data structure changed quite a bit (each event is now an object with attributes, rather than a tuple).

I'm ok with this patch. Be aware that if we land the #1170 patches (specifically [1170-p2.diff](/tahoe-lafs/trac-2024-07-25/attachments/000078ac-1c90-b882-d4ac-81973208d8b2)) then this one will need to be rewritten, since the download-status data structure changed quite a bit (each event is now an object with attributes, rather than a tuple).

zooko commented

2010-08-31 23:47:27 +00:00

François, could you rewrite your patch to be based on top of Brian's #1170 patches? :-)

zooko commented

2010-09-02 05:51:10 +00:00

Okay I have applied two out of three of Brian's patches, namely changeset:c89a464510394089 and changeset:00e9e4e6760021a1. changeset:00e9e4e6760021a1 is the one that was formerly known as 1170-p2.diff.

Okay I have applied two out of three of Brian's patches, namely changeset:c89a464510394089 and changeset:00e9e4e6760021a1. changeset:00e9e4e6760021a1 is the one that was formerly known as [1170-p2.diff](/tahoe-lafs/trac-2024-07-25/attachments/000078ac-1c90-b882-d4ac-81973208d8b2).

francois commented

2010-09-02 10:49:03 +00:00

Replying to warner:

I'm ok with this patch. Be aware that if we land the #1170 patches (specifically 1170-p2.diff) then this one will need to be rewritten, since the download-status data structure changed quite a bit (each event is now an object with attributes, rather than a tuple).

Well, the download-status data structure are actually changed by 1170-p3.diff which is not yet commited in trunk. Anyway, here's an up to date version of the patch.

Replying to [warner](/tahoe-lafs/trac-2024-07-25/issues/1172#issuecomment-79672): > I'm ok with this patch. Be aware that if we land the #1170 patches (specifically [1170-p2.diff](/tahoe-lafs/trac-2024-07-25/attachments/000078ac-1c90-b882-d4ac-81973208d8b2)) then this one will need to be rewritten, since the download-status data structure changed quite a bit (each event is now an object with attributes, rather than a tuple). Well, the download-status data structure are actually changed by [1170-p3.diff](/tahoe-lafs/trac-2024-07-25/attachments/000078ac-1c90-b882-d4ac-8dc2395ab874) which is not yet commited in trunk. Anyway, here's an up to date version of the patch.

francois commented

2010-09-02 10:49:16 +00:00

Attachment downloader-status-1172-2.dpatch (4646 bytes) added

**Attachment** downloader-status-1172-2.dpatch (4646 bytes) added

downloader-status-1172-2.dpatch

4.5 KiB

francois@ctrlaltdel.ch commented

2010-09-02 14:58:08 +00:00

In changeset:485bfc0fd67ef421:

DownloadStatus: show active immutable downloads in Active Operations, Fix #1172

In changeset:485bfc0fd67ef421: ``` DownloadStatus: show active immutable downloads in Active Operations, Fix #1172 ```

tahoe-lafs added the

fixed

label 2010-09-02 14:58:08 +00:00

tahoe-lafs closed this issue

2010-09-02 14:58:08 +00:00

zooko commented

2010-09-02 15:56:11 +00:00

Oh look this failed unit tests:

http://tahoe-lafs.org/buildbot/builders/Kyle%20OpenBSD-4.6%20amd64/builds/390/steps/test-coverage/logs/stdio

[ERROR]: allmydata.test.test_download.Status.test_active

Traceback (most recent call last):
  File "/home/buildbot/tahoe-lafs/Kyle OpenBSD-4.6 amd64/build/src/allmydata/test/test_download.py", line 1267, in test_active
    self.failUnlessEqual(ds.get_active(), True)
  File "/home/buildbot/tahoe-lafs/Kyle OpenBSD-4.6 amd64/build/src/allmydata/immutable/downloader/status.py", line 210, in get_active
    if r_ev["finish_time"] is None:
exceptions.TypeError: tuple indices must be integers, not str

Oh look this failed unit tests: <http://tahoe-lafs.org/buildbot/builders/Kyle%20OpenBSD-4.6%20amd64/builds/390/steps/test-coverage/logs/stdio> ``` [ERROR]: allmydata.test.test_download.Status.test_active Traceback (most recent call last): File "/home/buildbot/tahoe-lafs/Kyle OpenBSD-4.6 amd64/build/src/allmydata/test/test_download.py", line 1267, in test_active self.failUnlessEqual(ds.get_active(), True) File "/home/buildbot/tahoe-lafs/Kyle OpenBSD-4.6 amd64/build/src/allmydata/immutable/downloader/status.py", line 210, in get_active if r_ev["finish_time"] is None: exceptions.TypeError: tuple indices must be integers, not str ```

zooko removed the

fixed

label 2010-09-02 15:56:11 +00:00

zooko reopened this issue

2010-09-02 15:56:11 +00:00

zooko commented

2010-09-02 16:20:41 +00:00

Oh this was my mistake, I should have committed attachment:downloader-status-1172.dpatch, not downloader-status-1172-2.dpatch . I'll commit a new patch that undoes the effect of downloader-status-1172-2.dpatch and then another patch that has the same effect as attachment:downloader-status-1172.dpatch. By the way, one thing you can do to make it harder for me to make such mistakes is to use the --ask-deps option to darcs record and specify that a patch depends on another patch. Then when I try to commit your patch, darcs will tell me that I can't do so until I commit that other patch, which will make me realize that I'm trying to commit the wrong patch.

Thanks!

Oh this was my mistake, I should have committed attachment:downloader-status-1172.dpatch, not [downloader-status-1172-2.dpatch](/tahoe-lafs/trac-2024-07-25/attachments/000078ac-e41c-8fd8-d6da-c44e834a13ec) . I'll commit a new patch that undoes the effect of [downloader-status-1172-2.dpatch](/tahoe-lafs/trac-2024-07-25/attachments/000078ac-e41c-8fd8-d6da-c44e834a13ec) and then another patch that has the same effect as attachment:downloader-status-1172.dpatch. By the way, one thing you can do to make it harder for me to make such mistakes is to use the `--ask-deps` option to `darcs record` and specify that a patch depends on another patch. Then when I try to commit your patch, darcs will tell me that I can't do so until I commit that other patch, which will make me realize that I'm trying to commit the wrong patch. Thanks!

zooko@zooko.com commented

2010-09-02 16:36:07 +00:00

In changeset:63fb687a440e99a9:

download status: fix bug from me committing the wrong one of François's #1172 patches, fixes #1172

In changeset:63fb687a440e99a9: ``` download status: fix bug from me committing the wrong one of François's #1172 patches, fixes #1172 ```

tahoe-lafs added the

fixed

label 2010-09-02 16:36:07 +00:00

tahoe-lafs closed this issue

2010-09-02 16:36:07 +00:00

Sign in to join this conversation.

No Label

LeastAuthority.com automation

code-frontend-ftp-sftp

code-frontend-magic-folder

somebody else's problem

No Milestone

No Assignees

3 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: tahoe-lafs/trac-2024-07-25#1172