[ZendTo] Problem updating 6.05-4 to 6.13-3

[John Thurston]

A little more information. I've lifted the cover and peeked at the data 
tables in the sqlite database.

It looks like I have several 'requests' with "Expiry" values of 
4080127620 and 4083327900. If my epoch calculations are correct, those 
are April 17, 2099 and May 24, 2099  So I suppose it is little wonder 
that the reaping process hasn't cleaned them out. It is interesting that 
they all have the same "SrcEmail", and were created at 1713286033 and 
1716486355 (April 16, 2024 and May 23, 2024). It kind of looks like they 
were assigned a 75-year lifetime.

And it looks like that is just an editable number in the 6.05 web 
interface. "Drop-off must occur between XXX and YYY", and the fields are 
user-editable with no limits. Where the 6.13 interface has a nice little 
calendar control, managed by the new 'maxRequestEndDays' setting. So my 
user in April was tricky, and simply changed the '2024' in that text box 
to '2099', giving me entries in my 'reqtable' which the reaper will 
never act on.

It looks like in 6.13, 'Requests' can be deleted from the "Global 
Drop-off List" in the same way that 'Dropoffs' can be deleted in 6.05.

So my hunch is, I can proceed with my 6.05 --> 6.13 update. And when it 
is done, I can use the "Global Drop-off List" to select and delete those 
long-lived 'requests'.

--
Do things because you should, not just because you can.

John Thurston    907-465-8591
John.Thurston at alaska.gov
Department of Administration
State of Alaska

On 11/13/2024 7:44 AM, John Thurston via ZendTo wrote:
>
> I can see what you mean when I look at my new-to-me 6.13 
> test-installation. Thank you for the guidance.
>
> On that system, after I make a 'request', the "Global Drop-off List" 
> has similar looking numeric "Claim ID" (e.g. "828 320 622") and the 
> word "Request" in the "Size" column. Interestingly, the 'requests' are 
> shown with yellow backgrounds in the table cells.
>
> On the system I updated from 6.05 --> 6.13, the numeric entries 
> appeared with "0" (zero) in the "Size" column (rather than the word 
> "Request"). And they appeared in the same table color-scheme as all of 
> the drop-offs.
>
> On that system, the entries carried dates ranging from 20240416 --> 
> 20241112 (our requests should expire after 7 days). They all appeared 
> with numeric "Claim ID", "0" in the "Size", and with no distinctive 
> background. So my concerns here are:
>
>   * Some parts of the code recognize them as Requests, other parts
>     seem not to
>   * New Requests must be stored differently than old instances, as
>     they are displayed differently in the Global List
>
>  1. Will these Old Requests (which display differently), behave as
>     expected?
>  2. Will the ancient Requests now be caught by the reaper?
>
> I can live with yes or no for either question. I'd like to know what 
> to tell my customers to expect.
>
> --
> Do things because you should, not just because you can.
>
> John Thurston    907-465-8591
> John.Thurston at alaska.gov
> Department of Administration
> State of Alaska
> On 11/13/2024 6:51 AM, jules at zend.to wrote:
>> The ones with the numeric values should be labelled as "requests" in 
>> one of the other columns. They are requests-for-dropoffs, not 
>> dropoffs themselves. They should get cleared up like they have been 
>> in the past, it's just now they show in that table.
>>
>> Cheers,
>> Jules.
>>
>>
>> On 13/11/2024 3:25 pm, John Thurston via ZendTo wrote:
>>>
>>> Updating our test-system seemed to work perfectly. Not so for 
>>> production.
>>>
>>> After updating from 6.05-4 to 6.13-3, I have some strange behavior 
>>> (and have reverted to the old, by way of a VMWare snapshot).
>>>
>>> New drop-off and pickup seems to work as expected. Picking up recent 
>>> drop-offs seemed to work as expected. But the "Show All Drop-offs" 
>>> now contains some entries with numeric values (e.g. "235 637 597") 
>>> in place of the expected strings (e.g. "22iUmVdjs9WxszxD"). I 
>>> exported all of the drop-offs to a CVS. All of the numeric clamIDs 
>>> show a zero size. And most of them are well past their expiration 
>>> date. Most are only a little old, but some are more than 6-months old.
>>>
>>> So I /suspect/ there are some old entries in the database which 
>>> weren't cleaned up in the normal course of operations. The new code 
>>> in 6.13 is finding them, interpreting them, and adding them to the 
>>> list of available downloads. I also /suspect/ that the next reaping 
>>> through the database by the new code would clean them out.
>>>
>>> But I couldn't be sure, so I've reverted to 6.05 while I try to 
>>> figure out what it is doing and if it is safe.
>>>
>>> I know that 6.13 is now a couple of years old, so others probably 
>>> performed their update in the distant past. But does anyone have any 
>>> insight or advice?
>>>
>>>
>
> _______________________________________________
> ZendTo mailing list
> ZendTo at zend.to
> http://jul.es/mailman/listinfo/zendto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jul.es/pipermail/zendto/attachments/20241113/e32af2ee/attachment.html>