create rc-processing-transaction

[kneeyo1]

This creates rc processing transactions redis cluster specifically for transactions. For now as part of the rollout, this only initializes the new eventstore and refactors a lot of the code so that most of the processing and post processing is aware of the event type.

[lynnagara]

there's a lot of places in code where you need to implement the dual writing, have you considered putting the dual writing logic in one place only inside the transaction_processing_store implementation, so that none of the callsites need to change when rolling this out?

[lynnagara]

i think there are a few more places in the codebase where this is needed.. e.g.

sentry/src/sentry/event_manager.py

Lines 1104 to 1107 in 939be86

	unprocessed = event_processing_store.get(
	cache_key_for_event({"project": event.project_id, "event_id": event.event_id}),
	unprocessed=True,
	)

can you check the whole codebase?

[kneeyo1]

i think there are a few more places in the codebase where this is needed.. e.g.

sentry/src/sentry/event_manager.py

Lines 1104 to 1107 in 939be86

	unprocessed = event_processing_store.get(
	cache_key_for_event({"project": event.project_id, "event_id": event.event_id}),
	unprocessed=True,
	)

can you check the whole codebase?

that is from the _nodestore_save_many function which checks first to ensure the event type is not a transaction

if event.get_event_type() not in ("transaction", "generic") and job["groups"]:

The rest of the references in the codebase are test cases (and reprocessing, which I'm not sure if it needs to be updated) but I think they don't need to know about the split

[markstory]

I think the reason was related to celery task pickling. We could put the string version of the enum values into task messages though.

[getsentry-bot]

PR reverted: 56b7027