#thread archive timestamp

1 messages · Page 1 of 1 (latest)

flat carbon
#

huh, interesting, i thought... let me see real quick

toxic cargo
flat carbon
#

hm, i do wonder how that comes to be
we get the creation timestamp from the ID the channel is made with on discords end

#

the archive timestamp is from the API

whole furnace
#
{
  id: '927142702292828170',
  guild_id: '222078108977594368',
  parent_id: '824411059443204127',
  owner_id: '83886770768314368',
  type: 11,
  name: 'thread archive timestamp',
  last_message_id: '927145147370713098',
  thread_metadata: [Object],
  message_count: 7,
  member_count: 3,
  rate_limit_per_user: 0
}
```• d.js 13.4.0 • Type: `object` • time taken: `186.756752ms`
#
{
  archived: false,
  archive_timestamp: '2022-01-02T10:19:24.883000+00:00',
  auto_archive_duration: 60,
  locked: false
}
```• d.js 13.4.0 • Type: `object` • time taken: `146.436063ms`
#
2022-01-02T10:14:05.705Z
```• d.js 13.4.0 • Type: `object` • time taken: `0.141826ms`
flat carbon
#

that is indeed not exactly the creation timestamp, curious

#

well, seeing that it's the case with raw API data I don't really see how we could do it any different @toxic cargo

flat carbon
toxic cargo
#

I want to check if a thread has been archived before.

#

Where can i report this error in the docs?

flat carbon
#

ah, i know why

#

if you start a thread on a message it will share it's id with said message

#

since i started this thread on a message you sent :14 the thread's creation (via our lib) will be at :14
where it really was created at :19 hence the archive timestamp being that

toxic cargo
#

Oh.

flat carbon
toxic cargo
#

My threads arent created on any message tho.

#

Still shows another value.

flat carbon
#

yup, less of a discrepancy, but there is one nonetheless

#

@green raven you implemented* threads, right? any idea what's going on here?
only idea i have atm is that the snowflake is generated before the thread is, and archive_timestamp is set to now() rather than the snowflake by discord?

green raven
#

try it with a private thread, my guess is it should be identical then

#

since public threads send a message first

#

if one doesn't exist

#

I thought archive_timestamp wasn't supposed to be set on create though (null)

flat carbon
flat carbon
flat carbon
green raven
#

guess it utilizes a similar code path but just doesn't send the message

flat carbon
#

i think the conclusion is still "no can do" then

green raven
#

yeah, this is on discords end

flat carbon
#

@toxic cargo thanks, that's a curious one, but we can't do anything to help you with determining if a thread has been archived prior
the best i can think of is a magic number margin at which you assume it's the same
(though true thread creation in case it was started on a message is also not available)

green raven
#

(i might poke AJ to send it as null on create when Discord is back from break)

flat carbon
#

and maybe send the actual creation timestamp, while you're at it
because for "created on messages" threads that's really a bit yuck

green raven
#

...yeah

flat carbon
#

we're currently suggesting wrong information there for thread creation times
because it's really the messages creation

green raven
#

this isn't nullable in the docs but the description suggests it is dead

#

because the archive status was never changed

toxic cargo
#

I will try to see if they timestambs are always the same number geater then the other one.

flat carbon
#

presumably not, but i think a margin would make sense

#

though that's also not available if created on a message, because the message was obv. created way before

green raven
#

that's inherited from channel

flat carbon
#

ah shit, so we can't even document that behaviour

green raven
#

its also documented wrong on the api docs

flat carbon
green raven
#

we can override jsdoc with virtual jsdoc for our docs

flat carbon
#

"If the channel is a thread channel created on a message this will reflect the creation of the message the thread was created on instead" moment

green raven
flat carbon
#

no need to hurry, but this is def. something we should somehow address

#

(and prob. something discord should look into as well, if they can. because ohboi is it confusing)

#

no idea why they didn't just send null to begin with...

  • a timestamp that reflects when XYZ was last changed
  • not null if never changed

like.. what even

#

at least we documented it as nullable, so IF they change we don't need to wait for a major release

green raven
#

virtual jsdoc ftw, no code changes

flat carbon
#

"can be"? is that also not a guarantee?

green raven
#

well idk

toxic cargo
#

You can create a thread with a starter message and not on a message.

green raven
#

if the message is old enough it sends a new one to create the thread on

flat carbon
#

o_O what

green raven
#

lets se

#

this is an old message, wonder what the timestamp says

flat carbon
green raven
#

well...Souji, here's the problem

#

discord doesn't generate that timestamp

flat carbon
#

am aware, we get it from the snowflake

#

but discord doesn't send ANY timestamp either

green raven
#

yeah

flat carbon
#

yet they send the archived thing, which is something close to creation if it wasn't changed ever
which is still not the one they created the snowflake with

#

presumably because the snowflake creation is external code to the thread creation

#

and thread creation uses now() in some manner

green raven
#

snowflake generation happens in isolated processes I believe (how they get their guaranteed unique structure)

flat carbon
#

ye, that's what i meant to imply with "external code"

#

which also means that, once archive status has been changed once, there is no time to get the creation time
(even with that approximation)

green raven
#

yeah, so...technically we just shouldn't have created* on threads it seems mmLol

flat carbon
#

that is what i'm starting to think

green raven
#

The only thing that we could maybe do is utilize the archive timestamp to fake created somehow, but that seems overly complex

flat carbon
#

or for discord to just send a timestamp instead of having us deconstruct snowflakes

  • and then suddenly making a feature where that just doesn't hold true anymore
green raven
flat carbon
#

the more this situation unfolded the more i realized how scuffed threads are implementation wise, in regards to the previous API

#

also opened a window into the assumptions we base our lib on, because that's the only choice we have

  • now if those assumptions don't hold true anymore... well.
green raven
#

well, AJ isn't on the API team, so this is client-first but cater to bot devs, kinda like timeouts...where we get no event on expiry so we're still tracking it manually dead It's these little things that make you realize the teams don't collaborate as much as you would hope

flat carbon
#

anyways, i'm out
if you wanna bring this up in #archive-internal-lib-discussions do feel free (re: removal/documentation)
maybe something for v14 to consider, though i'm not sure how that works either, looking at the inheritance structure
unless "implements ChannelThatHasCreation" or some scuffed shit like that

green raven
#

I really want to redo channel hiearchy at some point, because thread channel really wants to inherit from guild channel....it just doesn't share most of its properties, I smell more interfaces and I don't like that

flat carbon
#

y...yeah. it's all a bit of a mess

#

thanks for jumping in on short notice shibaHeart