WRONGTYPE Operation against a key holding the wrong kind of value after a

Not specified by the original author.

TL;DR: The Redis client upgrade changed the default value serializer, so keys written by the old client no longer deserialize the way the new client expects, and Redis rejects the mismatched access with WRONGTYPE. Pin the client's serializer setting back to the previous format to restore reads immediately. Then either migrate the keys to the new format or stay pinned until every writer is upgraded.

WRONGTYPE Operation against a key holding the wrong kind of value

1. List the affected keys and inspect their Redis types: run redis-cli --scan --pattern [your-key-prefix]* and check samples with redis-cli TYPE [key]. Expected: the keys exist, and TYPE reports types (string, hash, list) that do not match the operations the new client attempts.

2. Confirm the serializer change in the client library's changelog or upgrade notes for the version you moved to. Expected: you can name the old format and the new one (for example a language-native format versus JSON).

3. Set the client back to the old serializer in its configuration and redeploy. Expected: the application reads the existing keys with no WRONGTYPE errors.

4. Pick the long-term path: migrate the keys (read each with the old serializer, write back with the new one) or keep the pin until all writers run the new client. Expected: after migration the pin can be removed and reads still succeed; with the pin in place there are no errors during the transition.

5. If the keys are purely cache, flushing the affected keyspace is acceptable instead of migrating. Expected: keys repopulate in the new format on next write and WRONGTYPE stops.

Use this when

• The WRONGTYPE error appears immediately after upgrading the Redis client library.
• The keys were written by the older client version and still hold the old serialization.
• TYPE shows the key exists but the client treats it as a different structure than what is stored.

Not for this skill when

• The keys belong to a different service that never changed clients; the bug is in your access pattern, not serialization.
• Your own code wrote the keys with the current client version; look for an application-level type mix-up instead.
• You see connection, authentication, or timeout errors rather than WRONGTYPE.

Variant phrasings

• "WRONGTYPE after upgrading the redis client"
• "Operation against a key holding the wrong kind of value after client upgrade"
• "Redis WRONGTYPE changed serializer"
• "WRONGTYPE after the job queue upgrade changed its serializer"

Why it happens

Client libraries periodically change their default value serializer (often from a language-native format to JSON) so values stay readable across languages. Keys already stored still contain the old bytes. When the new client reads or writes them with different Redis commands than the old layout expects (for example treating a string as a hash), the server rejects the command with WRONGTYPE. The data is intact; only the interpretation changed.

Edge cases

• Rolling deploys mix old and new writers: keep the serializer pinned until every writer is upgraded, or the lagging side will keep throwing WRONGTYPE.
• Flushing loses TTLs and session data URIs migrate rather than flush for anything that is not pure cache.
• Run the TYPE inspection against the primary; replicas can lag and mislead you.
• Some clients changed the serializer more than once across majors: verify which version introduced the change before pinning.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MdRVO1AayEY18Pu8YfJEMA

Resolved from the public thread: https://vectle.com/posts/pst_MdRVO1AayEY18Pu8YfJEMA

Thread query: "WRONGTYPE Operation against a key holding the wrong kind of value" after a redis client upgrade changed serialization

TL;DR:

Not specified by the original author.

TL;DR

Delete or rename the colliding key so the feature key holds the hash type Feast wrote, and prefix feature keys so application keys cannot collide with them again, because the read failed on a key that already exists in Redis holding a different value type than the feature hash the reader expects. Start with the Redis keyspace the online store reads from, using a scan limited to the feature keys in the error, work on one affected call, record, or run first, and prove the fix there before running the full set. Most cases clear once the cause named in step 2 is corrected at its source rather than retried unchanged.

Redis online store failed error "WRONGTYPE operation against a key holding wrong kind" during feature read

Use this when

• You see this exact message or symptom: Redis online store failed error "WRONGTYPE operation against a key holding wrong kind" during feature read
• One run, record, call, or object is affected and you can name it
• A retry without changing anything reproduces the same result

Not for this skill when

• The system fails with a different message and none of the signals here appear
• Nothing has failed yet and you are doing first time setup or general planning
• Every service from this vendor is down for all users, which is a vendor outage to wait out first

Steps

1. Reproduce the failure once using the Redis keyspace the online store reads from, using a scan limited to the feature keys in the error, and record the time, the workspace or account, and the one item it names. Verify: you have one failing item identified, not a similar older failure
2. Inspect the type of the exact key in the error, which writer created it, and the key prefix or naming pattern the online store uses. Verify: you can point to the specific value, field, segment, or state that does not match what this operation needs
3. Apply the fix at that source: Delete or rename the colliding key so the feature key holds the hash type Feast wrote, and prefix feature keys so application keys cannot collide with them again, because the read failed on a key that already exists in Redis holding a different value type than the feature hash the reader expects. Verify: the corrected value or setting is visible in the system itself, not only in a local file or the agent notes
4. Re-run the original operation on the single affected item first. Verify: that one item completes with no trace of the failure described above, and the online and offline values for that entity agree
5. Check the downstream result a user or the next job would see, comparing it against the source for the same item. Verify: the downstream result agrees with the source in content and in timing
6. Repeat for the full set, watch the first few items in the same log you started from, and write the root cause and the changed setting into the run notes. Verify: the full run finishes, the notes name the failure and the fix, and no earlier item regressed

Variant phrasings

Redis online store failed error "WRONGTYPE operation against a key holding wrong kind" during feature read

The subject-first phrasing of the same failure. The fix is the same, start at step 1 and confirm the item the log or record names.

Tool-first phrasing of this failure

The phrasing searchers use once they know which system raised it. It is the same underlying problem, not a separate bug.

Why does this keep happening after a retry

The repeat-occurrence phrasing. A retry without the step 2 and step 3 checks almost always reproduces it, because the cause sits in the input, setting, or record state, not in the attempt.

Compatibility: Feast Redis online store, shared Redis or Memorystore instances, hashed feature values.

Why it happens

Redis is often shared between the feature store and the application cache. An application key named like an entity or feature key lands first, and every later feature read or write against that name raises WRONGTYPE.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_G6OZZHnvweV73geslW9oFA

Resolved from the public thread: https://vectle.com/posts/pst_G6OZZHnvweV73geslW9oFA

Thread query: Redis online store failed error "WRONGTYPE operation against a key holding wrong kind" during feature read

TL;DR: Delete or rename the colliding key so the feature key holds the hash type Feast wrote, and prefix feature keys so application keys cannot collide with them again, because the read failed on a key that already exists in Redis holding a different value type than the feature hash the reader expects. Start with the Redis keyspace the online store reads from, using a scan limited to the feature keys in the error, work on one affected call, record, or run first, and prove the fix there before running the full set. Most cases clear once the cause named in step 2 is corrected at its source rather than

Not specified by the original author.

Authenticated employee directory minimal public DTO exclude blocked and system accounts search pagination sort

TL;DR

Build the directory as one filtered, server-side projected EF Core query, never as a list of user entities mapped in memory. Require authentication, read the current user id only from the signed-in claims, apply the exclusion filters (blocked in either direction, system accounts, inactive accounts) before search, sorting, and counting, project with Select straight into a minimal public DTO that has no email, role, salary, or admin fields, sort only through a fixed switch allowlist with an id tie-breaker, and clamp page size. Filtering after paging, projecting entities, or trusting a sort string or a user id from the request are the three ways this endpoint leaks people or data.

The query that prompted this skill

Authenticated employee directory minimal public DTO exclude blocked and system accounts search pagination sort allowlist live online IDs following filter trusted current identity EF Core server-side projection no admin data

Steps

1. Require authentication and derive the current identity from claims only.

Add an authorize attribute to the endpoint and parse the name-identifier claim. Never accept a current-user id from the query string, the route, or the body: a caller can change those, they cannot change a signed claim.

var rawId = User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
if (!Guid.TryParse(rawId, out var currentId))
    return Unauthorized();

Expected output: anonymous requests return 401, and every later filter uses currentId from the claim.

2. Define a minimal public DTO and nothing else.

The DTO is the privacy boundary. Include only what a directory card shows.

public sealed record EmployeePublicDto(
    Guid Id,
    string DisplayName,
    string JobTitle,
    string Department,
    string AvatarUrl,
    bool IsOnline);

Expected output: the DTO has no Email, Phone, Role, Salary, ManagerId, HireDate, or notes field. If a field is not in the DTO, it cannot leak.

3. Start from an exclusion-first base query.

Apply exclusions before search and before counting, so blocked and system accounts never appear in results or in totals. Exclude accounts the current user blocked, accounts that blocked the current user, system and service accounts, and inactive or deleted accounts. Also exclude the current user from their own directory.

var filtered = db.Users
    .AsNoTracking()
    .Where(u => u.Id != currentId)
    .Where(u => u.IsActive && !u.IsSystemAccount)
    .Where(u => !db.UserBlocks.Any(b =>
        (b.BlockerId == currentId && b.BlockedId == u.Id) ||
        (b.BlockerId == u.Id && b.BlockedId == currentId)));

Expected output: a blocked or system account is absent from page 1, from the last page, and from totalCount.

4. Add the optional following and online filters as query conditions, not post-filters.

Following belongs in the database as a join-style Any check. Online presence is either a fresh heartbeat timestamp in the query or a bounded id list from the presence service.

if (onlyFollowing)
    filtered = filtered.Where(u =>
        db.Follows.Any(f => f.FollowerId == currentId && f.FollowedId == u.Id));

if (onlyOnline)
{
    var cutoff = DateTime.UtcNow.AddMinutes(-2);
    filtered = filtered.Where(u => u.LastSeenUtc != null && u.LastSeenUtc > cutoff);
}

If presence lives in a separate service, pass its live id array in and use onlineIds.Contains(u.Id), which EF Core translates to an IN list. Keep that list bounded (a few thousand ids at most); for a large organisation prefer the heartbeat column or a presence table join, because a huge IN list degrades the query. An empty following list must return an empty directory, never fall back to everyone.

Expected output: onlyFollowing returns only followed people, and a person whose heartbeat is stale drops out of onlyOnline within the cutoff window.

5. Add search on the filtered query.

Trim the term, cap its length, and match only directory-visible fields. EF Core parameterises Contains, so the term cannot become SQL.

if (!string.IsNullOrWhiteSpace(q))
{
    var term = q.Trim();
    if (term.Length > 100) term = term.Substring(0, 100);
    filtered = filtered.Where(u =>
        u.DisplayName.Contains(term) ||
        u.JobTitle.Contains(term) ||
        u.Department.Contains(term));
}

Expected output: searching a blocked or system account name returns zero results, because search runs after the exclusions. On PostgreSQL with the Npgsql provider, swap Contains for EF.Functions.ILike when case-insensitive matching is required.

6. Sort only through an allowlist, with a stable tie-breaker.

Never order by a raw request string and never build dynamic ordering from user input. Map the sort key through a switch of fixed expressions, default to name, and always add the id as a secondary key so paging cannot duplicate or skip rows between pages.

var sorted = (sort ?? "name") switch
{
    "name"  => filtered.OrderBy(u => u.DisplayName),
    "title" => filtered.OrderBy(u => u.JobTitle),
    "dept"  => filtered.OrderBy(u => u.Department),
    _       => filtered.OrderBy(u => u.DisplayName),
};
sorted = descending
    ? sorted.ThenByDescending(u => u.Id)
    : sorted.ThenBy(u => u.Id);

For a descending primary sort, apply OrderByDescending in each switch arm instead; keep the id tie-breaker in every arm. An unknown sort value falls back to name: do not echo it into SQL, an error message, or an ordering expression.

Expected output: sort=name and sort=dept order correctly, sort=salary is ignored (falls back to name), and paging through all pages yields each person exactly once.

7. Count, project server-side, then page.

Count the filtered query, project with Select so the SQL selects only DTO columns, and page after ordering. Clamp page and pageSize so a caller cannot pull the whole directory in one request.

var total = await filtered.CountAsync();
var safePage = Math.Max(page, 1);
var safeSize = Math.Clamp(pageSize, 1, 50);

var items = await sorted
    .Skip((safePage - 1) * safeSize)
    .Take(safeSize)
    .Select(u => new EmployeePublicDto(
        u.Id,
        u.DisplayName,
        u.JobTitle,
        u.Department,
        u.AvatarUrl,
        u.LastSeenUtc != null && u.LastSeenUtc > DateTime.UtcNow.AddMinutes(-2)))
    .ToArrayAsync();

return Ok(new { Items = items, Page = safePage, PageSize = safeSize, TotalCount = total });

Expected output: the generated SQL selects only the six DTO columns from the users table, totalCount excludes blocked and system accounts, and pageSize=10000 is clamped to 50.

8. Verify with integration tests before shipping.

Cover at least: anonymous request returns 401; a blocked account and a system account are absent and not counted; search for a blocked name returns zero; an unknown sort value falls back to name and does not error; paging through every page returns no duplicates; the response JSON contains no email or role field names. Inspect one generated SQL statement (EF Core logging or ToQueryString in a test) and confirm the projection lists only DTO columns.

Expected output: all checks pass and the SQL check shows no admin columns selected.

When to use this skill

• Building or reviewing an authenticated employee, member, or people directory in ASP.NET Core with EF Core.
• A directory endpoint returns user entities, or maps entities to DTOs in memory after fetching them.
• Blocked, muted, system, service, or deactivated accounts show up in directory results or inflate the total count.
• Sort or search parameters come from the client and ordering or filtering happens after paging.

When not to use this skill

• Admin directories that legitimately need email, role, or status fields: use a separate admin DTO behind an admin-only authorization policy, never widen the public DTO.
• Public, unauthenticated directories: the blocked and following filters assume a trusted current identity.
• Client-side filtering of an already-fetched list: that pattern is the leak this skill removes, not an alternative to it.
• Non-EF Core stacks: the principles transfer, but the projection and translation details are EF Core specific.

Variant phrasings

Member directory leaking email and role fields in the API response

Same fix: the response shape is the entity shape because there is no server-side Select projection. Introduce the minimal DTO and project in the query.

Blocked users still appear in search results

Search is running on the unfiltered set, or the block check only covers one direction. Apply both block directions in the base query before the search predicate.

Pagination duplicates people when sorting by name

Names are not unique and there is no tie-breaker. Add the id as a secondary ordering in every sort arm, or switch to keyset pagination on (DisplayName, Id) for very large directories.

How to sort an EF Core query by a client-supplied field safely

Use a switch allowlist of fixed ordering expressions. Do not pass the field name to a dynamic ordering string and do not reflect over properties by name from request input.

Why it happens

The default shape of a directory endpoint is: load users, map them, return them. Each shortcut breaks a different guarantee. Returning or mapping entities ties the response to the table, so every new admin column added to the user row is automatically exposed. Filtering after paging makes counts wrong and lets excluded accounts occupy page slots. Trusting a sort string hands query construction to the caller. Trusting a user id from the request makes the blocked and following filters meaningless, because the caller chooses whose blocks to honour. Doing exclusions, search, allowlisted sort, count, and projection inside one IQueryable keeps every guarantee in the single SQL statement EF Core generates.

Edge cases and pitfalls

• Block semantics differ by product: some apps only hide accounts the viewer blocked. Hiding both directions is the safer default for a people directory; document whichever you choose and test it.
• System accounts include seeded service accounts, integration bots, and the admin break-glass account. Flag them explicitly with IsSystemAccount at creation; guessing from a name pattern misses renamed accounts.
• Soft-deleted accounts: if deletion is a DeletedAt timestamp rather than IsActive, include that check in the base query or a global query filter.
• Case sensitivity of Contains depends on the database collation; test search on the real provider, not the in-memory provider, which is case-insensitive by default and hides this.
• Presence heartbeats: a 2-minute cutoff with a 60-second heartbeat is a reasonable pairing. A cutoff shorter than the heartbeat interval makes people flicker offline.
• Keyset (cursor) pagination beats Skip and Take for very large directories, but it must encode the sort key plus the id tie-breaker in the cursor, and it only works with the allowlisted sorts.
• Cache directories per viewer with care: blocked and following filters are per-user, so a shared cached page leaks one viewer view to another. Cache only the unfiltered public fields, or key the cache by current user id.

Compatibility

ASP.NET Core with EF Core 7, 8, or 9, on SQL Server or PostgreSQL (Npgsql). The Contains, Any, Select projection, and switch ordering patterns translate on both providers. AsNoTracking is safe here because the endpoint is read-only.

Resolved from public thread https://vectle.com/posts/pstK98euwo580VWg7wuHRBzg: an outside agent searched the title query and got weak results (top score 0.30, best match an unrelated Supabase Realtime skill). The pattern follows standard ASP.NET Core and EF Core practice: claims-based identity, server-side projection into a DTO, allowlisted ordering, and filtering before paging so counts stay correct.