Bump vite from 4.4.4 to 6.4.2 in /cmd/relay/relay-admin-ui#1382
Open
dependabot[bot] wants to merge 4309 commits into
Open
Bump vite from 4.4.4 to 6.4.2 in /cmd/relay/relay-admin-ui#1382dependabot[bot] wants to merge 4309 commits into
dependabot[bot] wants to merge 4309 commits into
Conversation
One might need custom plc directory endpoint other than <https://plc.directory> for testing purposes or for plc mirrors. As tap supports full network backfill, it would be better to test that on sandboxed atproto infra than public infra with ~40M repos. So I added a `plc-url` flag and `TAP_PLC_URL` env var. Same as relay, `ATP_PLC_HOST` env var can also be used instead.
As indicated in the comment, adding an actual foreign key relationship would probably help with this. But doing it as a query tweak is a simpler change to deploy (no schema change).
Seeing lots of crashes in rainbow due to us sending to `s.outgoing` even though it's already been closed. This is clearly a bandaid, but we need a fix ASAP, and this should probably be in there anyways <img width="1608" height="823" alt="image" src="https://github.com/user-attachments/assets/ce0ba2d3-b9a4-4564-9de9-3b69070ef67b" /> ^ note that large recent missing data blip was me cutting the rainbow process over to a new management system. Had a bit of downtime (sorry!)
Resyncer was setting `retry_after` but then not actually respecting it when claiming a job Closes #1239
We were verifying structure of commit, but not verifying the signature itself. Closes #1238
Follow up to #1247 Ensure we're retrying errored repos and increase backoff to 1-60min as opposed to 1-60s
just a tiny typo fix
Reflects the changes from bluesky-social/atproto#4440.
…rrors (#1257) When Tap restarts, the EventManager loads existing events from the database but doesn't initialize the nextID counter. This causes new events to be assigned IDs starting from 0, which collide with existing database records. The fix restores the nextID counter as events are loaded, ensuring new IDs are always greater than any existing database IDs. Fixes #1253
This reverts commit 2c00289.
This reverts commit 2c00289. We need to remove this field here and from `@atproto/bsky`, deploy the lexicon without it, and then re-add it as string. Long story short: `recId` is an `int64` and TS/JS cannot get the machine ID out of it because it can't handle big integers unless with explicity `BigInt` — which is not the case in our stack. So we're gonna pass it ias string instead. Related PRs: * bluesky-social/atproto#4440 * #1263 * bluesky-social/seeemore#155 * bluesky-social/seeemore#158
github.com/bluesky-social/indigo/api/atproto was imported twice, the second time under an alias. This commit removes the duplicated import.
github.com/bluesky-social/indigo/api/atproto was imported twice, the second time under an alias. This commit removes the duplicated import.
(this is on top of the Go v1.26 PR; we should merge that first)
An initial batch of `go fix ./...` changes. We are likely to want to
merge in more auto-fixes, but this is a broad start for things like
for/range, `interface{}` to `any`, `wg.Go()`, etc. I manually skimmed
all of these and they seem safe.
Simply updates to Go v1.26. Have a follow-up PR with some `go fix ./...` updates. Most of our go repos which depend on indigo have already been updated, but I have separate PRs out for some straglers.
This fixes two dropped `err` variables in `atproto/auth`. I tried to follow the most canonical use of `%w` in a `fmt.Errorf`. If this project follows a different standard, I'll happily change it. Unit tests passed both before and after changes.
This picks up a dropped test error in `lex/util`.
The motivation is that we are looking at doing a "gallery" embed type on bsky posts, and want to constrain the increase in concurrent goroutines. In particular, the number of concurrent HTTP requests being made by automod to PDS instances to download the blobs: we don't want automod to get rate-limited if it is doing dozens of concurrent blob requests to a small/simple PDS due to a single record; or to DDoS that type of PDS instance if it does not have limits on concurrent requests in place. Note that this patch does *not* add concurrency limits on processing rules for individual blobs. If an automod process had 20 blob rules, and concurrent blob processing of 8x, it might start 160 processing goroutines at the same time. This is expected to be fine because blob rules are usually "per service", and these requests would be going to separate backend services. The best way to constrain concurrency there is to limit the overall number of worker queues. Note that i'm not using `errgroup.WithContext` (doesn't seem needed), and that i'm doing the old-fashioned `blob := blob` variable re-assignment in the for-loops out of habit, even though loop vars were fixed in Go 1.22. Mostly requesting review from Rafael, but also tagging Jim for review (if he has time) just for idiomatic Go concurrency patterns.
In this new version of the relay, only the account limit is actually editable. This clarifies this by making the other event limits static (not editable)
Adds a **non-breaking change** to `backfill` package. * With `.Start()` it would use the default logger * This PR adds `StartWithLogger(*slog.Logger)` so the user can use a custom logger * Now `Start()` just wraps the default logger in a `StartWithLogger` call (so, not breaking the API) (the two other minor changes are from the linter)
Motivation is to make it clearer how to operate the relay, eg when bumping limits. Only the account limit is actually editable. Also a small patch to improve logging/printing at startup (uses slog instead of 'echo' web framework default port printing).
Bumps [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite) from 4.4.4 to 6.4.2. - [Release notes](https://github.com/vitejs/vite/releases) - [Changelog](https://github.com/vitejs/vite/blob/v6.4.2/packages/vite/CHANGELOG.md) - [Commits](https://github.com/vitejs/vite/commits/v6.4.2/packages/vite) --- updated-dependencies: - dependency-name: vite dependency-version: 6.4.2 dependency-type: direct:development ... Signed-off-by: dependabot[bot] <support@github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps vite from 4.4.4 to 6.4.2.
Release notes
Sourced from vite's releases.
Changelog
Sourced from vite's changelog.
... (truncated)
Commits
6b3fad0release: v6.4.2ca4da5dfix: avoid path traversal with optimize deps sourcemap handler (#22161)fe28e47fix: apply server.fs check to env transport (#22159) (#22163)5487f4frelease: v6.4.11114b5dfix(dev): trim trailing slash beforeserver.fs.denycheck (#20968) (#20969)f12697crelease: v6.4.0ca6455efeat: allow passing down resolved config to vite's createServer (#20932)0e173d8release: v6.3.7c59a222fix(esbuild): inject esbuild helpers correctly for esbuild 0.25.9+ (#20940)3f337c5release: v6.3.6Maintainer changes
This version was pushed to npm by GitHub Actions, a new releaser for vite since your current version.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)You can disable automated security fix PRs for this repo from the Security Alerts page.