Commit graph

1519 commits

Author SHA1 Message Date
c81ffb6ac2 Remove unused @testing-library packages
Huh, guess I wrote some tests with these, then removed them, then never
removed these deps?

Only noticed because deploying failed on them for some reason, saying
the Node version was incompatible… I'm surprised by that, I don't know
when the locked version would have changed, maybe the team uploaded
some new metadata about our older versions and their compatibility
info?

In any case, we don't need the libraries, so *why* their install is
suddenly failing doesn't really matter too much. Goodbye!
2024-04-17 09:43:55 -07:00
37bac38973 Oops, fix list caching when removing items via Impress 2020
I realized this months ago when adding `updated_at` changes to the
other actions around here, and I just forgot this one, and I've had a
sticky on my desk about it since then! Finally done!

Before this change, clicking "I own this" or "I want this" on the item
page, while you own/want the item and it's in a specific list, would
remove the item from the list but *not* update the list's `updated_at`
timestamp. Now, it does!

This affects caching on main DTI, which relies on the list's
`updated_at` to decide when to render new HTML.
2024-04-17 09:37:50 -07:00
242665bd02 Oh wow, don't use the images.neopets.com asset proxy anymore either!
Huh, I was writing up an API inventory doc to send to TNT, and was
gonna explain why we proxy these assets… but turns out we don't need to
anymore! Nice!

This is a bit fragile if they ever change their headers, so I'll
mention that in the doc, but for now, yeah sure let's save the planet
some computational effort!
2024-04-06 03:39:05 -07:00
1617b82b18 Don't use the pets.neopets.com asset proxy anymore
Ah right, now that HTTPS works, we can skip this!
2024-04-06 03:26:36 -07:00
584fed70c6 Oops, touch list updated_at when adding/removing items
Oh right, I forgot that 2020 has endpoints to add/remove items from
lists, so I didn't add logic that corresponds to the `touch: true` we
recently added in the Rails app to power caching!

This created a bug where adding/removing items from lists from the item
page would _not_ cause the cache to update in the Rails app when
sharing your list with others.

In this change, we add `UPDATE` queries to emulate that same logic!
2024-03-09 11:51:00 -08:00
eb915ae851 Update public data SQL (to fix 00:00:00 manifest timestamps)
I was surprised to find that ~65k `swf_assets` records had their
`manifest_cached_at` timestamp set to `0000-00-00 00:00:00`? I don't
literally see where in the code that could happen. Maybe it's old?

Anyway, it's causing a problem with the utf8 database migration I'm
working on, so I manually set all of those to `NULL` and saving this
so I can test the new migration against it!
2024-02-28 18:08:57 -08:00
c7950c0af2 Update public data SQL (to get Baby Body Paints)
Wanted to test more about these locally! :3
2024-02-27 18:02:04 -08:00
6b0f1853c3 Oops, fix error in modeling query on homepage
Okay, legit, I'm reading over this and I don't understand why `item_id`
isn't working here? It seems like we have `SELECT DISTINCT items.id AS
item_id`, and we use it in the `ORDER BY` clause right below. And I
don't see why, presumably, it's our item translations changes that
broke this?

But in any case, okay! This fixes it! Moving on!
2024-02-27 17:33:01 -08:00
6a6901ae39 Send feedback emails to matchu@openneo.net
I've reorganized my mailboxes a bit, and now I think it should 1) no
longer break to send them here, and 2) help me keep things better
organized!
2024-02-24 12:16:25 -08:00
c3529450bf Migrate away from item translations for modeling
Note that my dev database wasn't in a great state to test
`yarn model-needed-items` directly—which is the only *actual* call
site for the modeling code, because `USE_NEW_MODELING=1` was never
turned on for the 2020 app I think?

But it's looking great on modeling directly when the server is run with
`USE_NEW_MODELING=1`, so I'm just gonna trust it for now, and check the
cron logs sometime.
2024-02-20 16:49:26 -08:00
8948b6567e Migrate away from item translations for itemByName GQL query
I'm not sure where this is used, my guess is it's for NeoBot?
2024-02-20 16:36:59 -08:00
f196e2d8fe Migrate away from item translations for Lists page 2024-02-20 16:33:56 -08:00
28ddc3455b Migrate away from item translations for /modeling page 2024-02-20 16:32:39 -08:00
c455617362 Migrate away from item translations for item search 2024-02-20 16:31:45 -08:00
62531cfe34 Migrate most things from item translations
Not the modeling code yet though!
2024-02-20 16:30:32 -08:00
6686f13154 Remove unused validate-owls-data script
This migration is done, the script is no longer needed! Goodbye!
2024-02-20 16:13:02 -08:00
1cef0bea20 Export public data, with the new fields on the items table 2024-02-20 16:12:34 -08:00
ca7138d755 Update public data again
This time I'm getting the Banana Chia and stuff!
2024-02-18 11:27:21 -08:00
448561604c Future-proof our nginx config for IPv6
Today I learned that nginx requires a special invocation to listen to
IPv6 addresses as well as IPv4. On some of my other projects, this was
causing Let's Encrypt certificate renewal to fail, because Let's
Encrypt prefers to connect over IPv6 when an AAAA record is present, so
its challenges were always returning 404, because nginx wasn't
listening on IPv6.

This shouldn't be affecting impress-2020 in production, because we
don't have an AAAA record right now. But I'm just making this change in
all my projects, to make sure this doesn't bite me in the future!
2024-02-13 08:52:52 -08:00
179c492294 Update the public data export again, after deleting duplicate assets
We ran the new `rails swf_assets:remove_duplicates` task in the
`impress` repository, saving our work before (previous commit) and
after (this commit), in case we need to study the results or roll back!
2024-02-09 09:55:02 -08:00
addce69855 Update the public data export
I'm about to work on purging duplicate SwfAsset records, so I'm making
sure I save everything first!
2024-02-09 09:06:35 -08:00
0e1b1eded3 Skip missing image layers in /api/outfitImage
Sometimes we don't have an image for an SWF asset. This can happen when
assets were converted to HTML5 without a PNG specified in the manifest.
(One example is bio/363, the Hind Biology for the Mutant Blumaroo.)

I'm noticing there's a second issue here on DTI's end, where it looks
like *we* have two copies of certain layers? I wonder if this was a bug
in like, the impress-2020 modeling code we tested at one point? Or if
this is in our main modeling code? e.g. the Mutant Blumaroo's bio/363
is in our database with DTI ID 192 and DTI ID 606955, and only the
former is registered as having an image (which we made ourselves and
host on S3).

So, I'm gonna start by just having the more graceful failure mode of
skipping the missing layer. But I'm also concerned about the root here,
I'll investigate!
2024-02-09 08:59:36 -08:00
8fb561338a Fix PetAppearance ID when there's an Alt Style
I don't think this actually affects any clients in practice, but now
that `PetAppearance` can be influenced not just by pet state ID but
also alt style ID, it's no longer correct to just use pet state ID as
the `id` (the default cache key). This could theoretically cause an alt
style to be locally cached as the default appearance of a
species/color/pose.

Instead, we now append an extra string in the case that there's also an
alt style influencing the appearance. This is a bit of a mess, because
I know there's some tooling that's expecting this field to be strictly
the pet state ID, mainly for support/debugging purposes I think? But I
imagine that's not a big deal in practice, and this change should
narrow the scope of a bug like that to just be like, "error: pet state
123-with-alt-style-456 not found" when trying to save a change to it
or something. Good enough!
2024-02-09 08:16:00 -08:00
98eb14853c Support alt styles in outfit thumbnails
Oops, before this change, outfits with alt styles would still show the
outfit as if no alt style were applied!

Now, we have the `Outfit` GraphQL type be internally aware of alt
styles, and set its `petAppearance` and `body` and `itemAppearances`
fields accordingly. No change was required to the actual
`/api/outfitImage` endpoint, once the GraphQL started returning the
right thing!

…because of that, I'm honestly kinda surprised that there's no obvious
issues arising with the Impress 2020 outfit interface itself? But it
seems to be correctly just, not showing alt styles at all, in the way I
intended because I never added support to it. So, okay, cool!
2024-02-08 10:51:52 -08:00
dc954d7c3c Stop referencing the {color,species,zone}_translations tables
We're in the process of migrating away from translating these records,
because Neopets hasn't supported non-English languages in many years,
and it'll simplify our code and database lookups.

In Main DTI, we already wrote code to copy these fields onto the main
records and keep them in sync for now; now, once DTI 2020 isn't
referencing them anymore, it should be safe for the main app to drop
the tables altogether.

Note that some Prettier changes got mixed in here and that's fine!

I also wasn't suuuper careful testing these, most of them seem to be
trivially testable by just loading the homepage or doing a few basic
wardrobe actions, and the others are in Discord support log actions
that aren't enabled in development mode, so I'm just like… ehh I'll do
a couple support actions after deploy and see that they don't crash!
2024-02-03 08:05:15 -08:00
4e1739cd16 Add CORS headers to /api/assetImage
Sometimes main DTI gets this back as the image URL for a movie asset,
we need to be able to request it!
2024-02-01 08:36:21 -08:00
f566012386 Add support for altStyleId to item search and appearance lookups
I'm not planning to port full Alt Style support over to the 2020
frontend, I really am winding that down, but adding a couple lil API
parameters are *by far* the easiest way to get Alt Styles working in
the main app because of how it calls the 2020 API.

So here we are, adding new API calls but not the frontend changes!
2024-02-01 04:59:09 -08:00
505f420d96 Update public data SQL dump, mainly to add alt styles
Note also the change to the public-data-constants, because we've
started (but not finished) moving name fields into the rows themselves
and deprecating the translations.
2024-02-01 02:01:50 -08:00
f2fd019aa8 Remove unused IMPRESS_LOG_IN_AS feature
The latest version of Yarn's shell interpreter wasn't playing nice with
this undefined variable; okay! It's unused, let's just delete all
trace of it!
2024-01-28 06:36:09 -08:00
106fcf075f Use the same dev database credentials as the main impress app
This should make it easier to test both apps working together!
2024-01-28 06:32:46 -08:00
ae287a0393 Update yarn lockfile
Another environment, another yarn version upgrade thing!
2024-01-28 06:31:47 -08:00
12dabffffa Fix MySQL host in yarn scripts 2024-01-24 00:16:03 -08:00
76476b1a45 Update my desktop SSH key
I did a pretty thorough reset of my desktop machine, and rather than go
spelunking for the same private key, I just rolled it over to a new
one. Let's set it up!
2024-01-14 03:09:20 -08:00
1a0f544f7b Move analytics to analytics.openneo.net
Self-hosted Plausible instance! I have need of usage numbers again,
after a good few years of just not using it; but I don't want to send
the data to Google, and I enjoy self-hosting things, so here we have it!

I actually forgot we were still sending the DTI 2020 numbers to
Plausible's cloud instance, oops! I stopped paying for it 😅 They do a
pretty good job anonymizing, so I'm not too worried about the practical
effects of that, but I'll be pleased to keep it more in-house going
forward.

I'm not sure why `async` isn't in the recommended tag anymore, but fine
by me!
2023-12-04 22:46:14 -08:00
4cd5cf5800 Fix handling of assets with https://images.neopets.com/temp SWF URLs
Weird! Well! This caused two issues.

One is that we used to filter down to only assets whose urls end in
`.swf`, because I never added support for the sound ones :p

The other is that we were using the SWF URL to infer the potential
manifest URLs, which we can't do when the SWF URL is a weird
placeholder!

Thankfully, just yesterday (wow!) we happened to have Classic DTI keep
track of `manifest_url` during the modeling process, and we backfilled
everything. So the most recent `temp` assets have their manifest! But
slightly older ones (not that old tho!!) didn't, so I manually inferred
the manifest URL from the asset's `remote_id` field instead (which
worked cuz there was no hash component to the manifest URL, unlike some
manifests).

The item "Flowing Black Cloak" (86668) on the Zafara is the one we were
looking at and testing with!
2023-11-11 13:28:47 -08:00
c3a9c24d22 Fix pet loading
Needed to add some headers to satisfy StackPath etc!

(Also, latest Prettier ran on this file for the first time, so a few
changes there too!)
2023-11-06 13:24:08 -08:00
74f6d112ee Disable Sentry
I want to restrict our monitoring just to the wardrobe-2020 fork on the
main app now!
2023-11-06 12:30:53 -08:00
0b9cec9c44 Fix some Typescript errors when using latest Next
Ran into these when building for deploy!
2023-11-02 16:50:05 -07:00
3b6bc0b6eb Oops, add Vary: Origin to GraphQL requests
Lol I guess we've probably just been having intermittent CORS issues
forever, oops. I hope the cache has been mostly warmed on the right
thing! But today I checked and the entire species/color picker on the
Rails app wasn't working for CORS reasons, so like. Yeah oof.
2023-11-02 16:35:11 -07:00
23f1f53b64 Upgrade to Next 12.3.2
I didn't really want to do this exactly, but I think installing a global
Typescript binary caused some problems here, where running the app had
started giving me an error like "you need to install `@types/react`!"
and I'm like. I did? years ago?

I searched for the error and people said "oh just upgrade Next" so I did
and now it's fixed I guess? I only bumped up to the latest version of
v12, rather than up to v14 where things are now, to avoid breakages. I
poked around the site ever so slightly and it seems fine, so I'm not
worried about it!
2023-11-02 16:33:33 -07:00
a2594d1797 Fix crash on user lists page from orphaned hangers
If you delete a closet list without deleting the items in it, it'll dump them into your default own/want lists. This isn't necessarily the behavior we really want, but oh well, that's the truth right now!

The GraphQL endpoint was assuming that all hanger `list_id` values were valid, oops! Now, we ignore list IDs that don't match a list.
2023-10-24 14:48:55 -07:00
53deee85dd Use MajorErrorMessage on user lists page
There's an error here that I'm trying to fix, first I'll make the error message nicer for people!
2023-10-24 14:43:43 -07:00
e70e67211e Restart the app every 8 minutes
Idk why it's memory leaking so hard lately? But let's uhhh just reboot it a ton for now, while we continue to work on migrating workloads offa there.
2023-10-17 01:00:23 -07:00
76dd8059bb Extract IMPRESS_MYSQL_HOST environment variable
Oh beans, I made an env variable change that I thought would switch us over to db.impress.openneo.net, and I was just plain wrong, darn. impress-2020 has been fully failing since then, oops!!!

Here, we change it to be an environment variable, so that in the future it will work how I want it to lol
2023-10-12 20:45:06 -07:00
a5dcf369bb Point the update link to the Pardon Our Dust page 2023-10-12 18:13:11 -07:00
a14bc9bebd Fix Vary header for CORS
Oops, we added behavior that varies the CORS response headers according to the incoming `Origin` header, but we forgot to add `Vary: Origin`!

This doesn't cause an issue for the app when you make requests to the server directly, but since it's behind a Fastly cache layer, we ended up caching responses that didn't include CORS headers but should have.

Now, this will instruct the Fastly cache to treat requests with different `Origin` headers as being entirely different. (This means we won't be sharing caches between requests from impress-2020 and the Rails app anymore, but that should be okay in practice!)
2023-10-12 14:58:26 -07:00
e31a79e793 Merge branch 'main' of github.com:openneo/impress-2020 2023-08-29 15:06:43 -07:00
756ee8dcb2 Add workaround for pet lookups with leading digits
This was Dice's idea ty!! Now, instead of crashing when looking up any pet whose name starts with a number, we do a clever lil workaround instead! We don't get *all* the data back (we're missing metadata), but that's fine for the main use case of typing your pet name in at the homepage.
2023-08-29 15:05:19 -07:00
80428e9834 Fix pet loading for most pets
Sigh, I guess xmlrpc was deleted? Back to the method that doesn't work for pets with leading digits in their names, sobbe

Dice has a neat idea for how to work around that, but I'm not sure how to fit it in our architecture, let's take a look!
2023-08-29 14:40:59 -07:00
85d68f68e1 Enable Classic DTI to access impress-2020 via CORS
owo, uwu,
2023-08-20 15:40:21 -07:00