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

Fri Nov 15 17:46:23 GMT 2024

Hi John,

Yes, that sounds entirely sensible. Clearly something I addressed in 
some version between 6.05 and 6.13. I might have even mentioned it in 
the ChangeLog somewhere... :-)

Cheers,
Jules.

On 13/11/2024 8:30 pm, John Thurston via ZendTo wrote:
>
> 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
>
> _______________________________________________
> ZendTo mailing list
> ZendTo at zend.to
> http://jul.es/mailman/listinfo/zendto

Jules

-- 
Julian Field MEng CEng CITP MBCS MIEEE MACM

'We have an asset out of containment.'
                             - Jurassic World

www.Zend.To
Twitter: @JulesFM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jul.es/pipermail/zendto/attachments/20241115/1201f9d6/attachment.html>