It's the new default debugger in ruby 3.1. Rails switched to it in 7.0,
avoids issues with Zeitwerk, has a more modern interface based on
current IRB, supports Unix Domain Sockets for remote debugging,
promises even better future maintenance due to being part of Ruby,
etc.
Change-Id: Ieaa7872f1c0308b16ae180fdb16df5dd6caa87a8
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/328241
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Isaac Moore <isaac.moore@instructure.com>
Build-Review: Isaac Moore <isaac.moore@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
refs AE-45
flag=none
test plan:
- specify `canvas_security` values in `vault_contents.yml`
- confirm they're loaded correctly when calling `CanvasSecurity` methods,
like `services_encryption_secret`, `services_signing_secret`, and
`services_previous_signing_secret`
Change-Id: Ib088eb2c123bcc32cfd6d67729916a6d7c5c2529
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/314607
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Isaac Moore <isaac.moore@instructure.com>
Product-Review: Isaac Moore <isaac.moore@instructure.com>
Build-Review: Isaac Moore <isaac.moore@instructure.com>
Reviewed-by: Aaron Ogata <aogata@instructure.com>
This change adds Sentry's distributed trace ID to the `X-Canvas-Meta`
response header, so that it may be ingested by the logging pipeline and
accessed downstream.
flag=none
refs DE-1032
test plan:
- with Sentry initialized with a valid DSN, verify that the
`X-Canvas-Meta` header contains a `st` value containing the Sentry
trace ID
- verify that the trace ID present in the response header matches the one
in the `meta` tag inside the body's `<head>`
- verify that when Sentry is not initialized with a valid DSN, the value
is omitted from the response header, and the app still renders
responses correctly
Change-Id: I63580b4d5057cebf55e6a4fdbc628d58ed7973f7
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/284991
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Isaac Moore <isaac.moore@instructure.com>
QA-Review: Jeremy Stanley <jeremy@instructure.com>
closes OREO-1234
flag = none
here is the problem:
- now some features use graphql endpoint to create canvas elements
- for example, recent discussion redesign use graphql queries
- but graphql requests dont have url path and query params for
app "pageview etl" when deciding page view and participation
here is the solution:
- discussed in OREO standup and detail can be found at OREO-1197
- to cover student activities, we added "operationName" in http
response "X-Canvas-meta"
- later, turbo log parser will pick up the operation name and
pass it to downstream app "pageview etl"
- later, pageview etl will use it to classify student activities
via graphql endpoint
here is the change:
- called "add-meta-header" function when the request parameters
have operation name field in it
- update unit tests accordingly
test plan:
- downloaded the change locally
- bundle update
- bundle exec rails server
- launch http://localhost:3000
- under your local organization, in account settings, enable feature
"discussion redesign"
- select a course
- if you don't have any discussion, act as a teacher and then create
a discussion
- command option i and open browser debugger
- under network tab, type "graphql"
- back to the ui, act as a student and use the student to open the
discussion created by the teacher
- in debugger, click the graphql endpoint entry, verify response header
"X-Canvas-Meta" has on=GetDiscussionQuery in it
- back to the ui, use the same student to reply the discussion
- in debugger, verify "X-Canvas-meta" has on=CreateDiscussionEntry in it
Change-Id: Ia7a208fb30dde18ac4b8413578ee6d1144283a22
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/277799
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
QA-Review: Kwok Lam <klam@instructure.com>
Product-Review: Kwok Lam <klam@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
namely, the graphql subgraph path
refs INTEROP-6704
flag = none
test plan:
- post to the subgraph endpoint with a base64-encoded request id
$ curl 'http://<canvas>/api/graphql/subgraph' \
-X POST \
-H "X-Request-Context-Id: $(echo sweet-request-id | base64)" \
-v
- the response should include this header
< X-Request-Context-Id: sweet-request-id
Change-Id: I46a905b893fd21643d5bf857fce8f54c9ab579e1
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/272478
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Michael Ziwisky <mziwisky@instructure.com>
Product-Review: Michael Ziwisky <mziwisky@instructure.com>
refs FOO-1649
Pull out middleware for request
context to a gem so that other
engines in canvas can use the
generator to look at the current
request for standard attributes
in the same way.
TEST PLAN:
1) requests should keep on getting context ids
2) sessions should keep getting added to the cookie jar
Change-Id: I9245491f722ac29c9544623ee14e0771ae248cd4
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/259609
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
Cody Cutrer