Table of Contents

• Changelog for 8.0.7

Changes in 8.0.7

Summary

• Bugfix - Return correct issuerAssignedId on /me: #12635
• Bugfix - Log unmapped thumbnail errors and always report a sabredav exception: #12663
• Enhancement - Eliminate redundant LDAP read-after-write on create and update: #12618
• Enhancement - Add an opt-in bounded LDAP connection pool: #12660
• Enhancement - Retry LDAP operations against a lagging replica: #12672

Details

• Bugfix - Return correct issuerAssignedId on /me: #12635

  The /graph/v1.0/me endpoint reported the internal user UUID as
  identities[].issuerAssignedId instead of the issuer-assigned identity (the
  OIDC sub). The endpoint took a fast path that built the user model from the
  CS3 user in the request context, which does not carry the external identity, so
  it fell back to the internal UUID. /me now always resolves the user through
  the identity backend, which reads the stored external identity and returns the
  correct value. Group memberships are still only expanded when $expand=memberOf
  is requested.

  #12635

• Bugfix - Log unmapped thumbnail errors and always report a sabredav exception: #12663

  The webdav service logged failures of the thumbnails service at debug level
  only. Errors which are not a property of the requested file, such as the
  thumbnails service being unreachable, were therefore invisible at production log
  levels: a complete preview outage produced HTTP 500 responses without a single
  log line explaining them. Unmapped errors are now logged at error level, while
  expected per-file outcomes such as an unsupported file type or a file still
  being processed stay at debug level. Two of the four thumbnail handlers also
  logged without the request context, so their messages carried no request id.

  In addition, codesEnum only mapped four status codes, so error responses for
  all other codes were rendered with an empty <s:exception></s:exception>
  element. The missing entries for 403, 425 and 429 have been added and any
  remaining unmapped code now falls back to a generic exception name, so clients
  always receive a usable exception.

  #12663

• Enhancement - Eliminate redundant LDAP read-after-write on create and update: #12618

  The graph LDAP backend no longer re-reads an entry immediately after writing it
  just to recover the entry ID for the response. When oCIS generates the ID itself
  (GRAPH_LDAP_SERVER_UUID disabled), the create response is now synthesized from
  the data already sent to the directory, and update responses are built by
  folding the applied modifications onto the entry that was read before the write.
  This avoids a round-trip that, against a replicated directory reached through a
  proxy, could hit a lagging replica and fail or return stale data.

  When the directory assigns the ID (GRAPH_LDAP_SERVER_UUID enabled), creates keep
  the existing read-back, since the generated ID cannot otherwise be recovered.

  #12618

• Enhancement - Add an opt-in bounded LDAP connection pool: #12660

  The auth-basic, users, groups and graph services can now be switched from a
  single long-lived reconnecting LDAP connection to a bounded pool of connections,
  so concurrent requests no longer serialize on one socket. Connections are dialed
  and bound lazily on checkout, unhealthy connections are discarded and lazily
  re-dialed rather than eagerly reconnected, and checkout blocks with a
  configurable timeout once the pool is exhausted.

  Pooling is off by default and fully backwards compatible. Enable it per service
  via 'OCIS_LDAP_POOL_ENABLED' (or the service-specific
  '_LDAP_POOL_ENABLED' override), and tune it with 'OCIS_LDAP_POOL_SIZE'
  (default 5) and 'OCIS_LDAP_POOL_CHECKOUT_TIMEOUT' (default 30s).

  The graph service's identity backend now shares the same LDAP client
  implementation used by the reva auth/user/group managers instead of maintaining
  its own separate reconnecting client.

  #12660

• Enhancement - Retry LDAP operations against a lagging replica: #12672

  The graph LDAP backend can now retry operations against a replicated directory
  where a write to the primary is followed by a read that lands on a replica which
  has not yet caught up. This covers the read-back that recovers a
  directory-assigned ID after a create (GRAPH_LDAP_SERVER_UUID enabled), which is
  retried until the entry becomes visible. The retry count and backoff are tunable
  through GRAPH_LDAP_RETRY_MAX_COUNT, GRAPH_LDAP_RETRY_BASE_DELAY and
  GRAPH_LDAP_RETRY_MAX_DELAY; the defaults keep the previous behaviour (a single
  immediate retry with no delay), so existing deployments are unaffected.

  Retries now distinguish reads from writes: a write is no longer retried on a
  network error, which can surface after the request was already sent and would
  otherwise apply the mutation twice.

  #12672