[SPARK-55129][SS] Introduce new key encoders for timestamp as a first class (UnsafeRow) by HeartSaVioR · Pull Request #53911 · apache/spark

HeartSaVioR · 2026-01-22T04:41:52Z

What changes were proposed in this pull request?

This PR proposes to introduce key encodings which include "timestamp" as the first class.

Proposed key encodings:

TimestampAsPrefixKeyStateEncoder / TimestampAsPrefixKeyStateEncoderSpec
- Place event time as a prefix, and key as remaining part of serialized format
TimestampAsPostfixKeyStateEncoder / TimestampAsPostfixKeyStateEncoderSpec
- Place key first, and event time as a postfix of serialized format

The type of timestamp is LongType (long) - when serializing the timestamp, we flip the sign byte and store the value as "big endian". This ensures the natural ordering of long type, across positive, 0, and negative values. The serialization format of the original key is the same, e.g. for UnsafeRow, same as underlying binary format.

These encodings are specification of prefix and range key encodings:

TimestampAsPrefixKeyStateEncoderSpec provides the range scan with timestamp.
TimestampAsPostfixKeyStateEncoderSpec provides the prefix scan with the key, additionally provides the range scan with the remaining timestamp. NOTE: The range scan with timestamp is only scoped to the same key.

Compared to the prefix/range key encoding, this can eliminate the overhead of combining two UnsafeRows, minimum 12 bytes in each key in overall (8 bytes of null-tracking bitset, 4 bytes of storing length for one of two UnsafeRows). It can also skip projection(s) from deserialization as well.

To cope with the existing StateStore API which does not have a concept of timestamp on API layer, we require the caller to project the key row to attach the timestamp manually before calling the StateStore API. Flipping the coin, the key row being produced by the StateStore API will be also the form of original row + timestamp and caller is responsible to project the original row from the returned row.

Note: the performance is not optimal since there are multiple places of projections (array creation and memcpy), and we will need to introduce API level of change to eliminate these projections.

The change is big already, so this PR only enables the new key encoding with UnsafeRow. Supporting Avro will be a follow up work.

Why are the changes needed?

The existing key encodings are too general to serve the same with noticeable overheads, in terms of additional bytes on serialized format. The proposed key encodings will do the same with minimized overhead, given the fact it only needs to handle timestamp along with the key.

Does this PR introduce any user-facing change?

No.

How was this patch tested?

New test suite.

Was this patch authored or co-authored using generative AI tooling?

Generated-by: claude-4.5-sonnet

The above is used for creating a new test suite. All other parts aren't generated by LLM.

github-actions · 2026-01-22T04:42:03Z

JIRA Issue Information

=== Improvement SPARK-55129 ===
Summary: Introduce State Store API and key encoders for event-time as a first class
Assignee: None
Status: Open
Affected: ["4.2.0"]

This comment was automatically generated by GitHub Actions

HeartSaVioR · 2026-01-23T05:30:00Z

TODO ticket for Avro : https://issues.apache.org/jira/browse/SPARK-55145

micheal-o · 2026-01-25T22:05:21Z

sql/core/src/main/scala/org/apache/spark/sql/execution/streaming/state/StateStore.scala

+ * The interface for event-time aware state operations, which are based on (key, eventTime, value)
+ * data structure instead of (key, value).
+ */
+trait EventTimeAwareStateOperations {


We want the APIs at the state store layer to be generic enough for reusability. This implementation is too tied to EventTime which is an operator level detail that shouldn't be coupled into the state store details.

We have a StateStoreRow class that allows passing in extra fields with an UnsafeRow. We use this for Row checksum too. So might be better to extend StateStoreRow and add eventTime field.

Then you can expose new state store APIs that take in StateStoreRow instead of UnsafeRow. Then this would make this implementation generic enough, that it can be reused for other use cases in the future and not tie it too much to event time.

micheal-o · 2026-01-25T22:05:35Z

...rc/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateStoreProvider.scala

+      require(keyEncoder.supportEventTime,
+        "EventTimeAwareStateOperations requires encoder supporting event time!")
+
+      override def get(key: UnsafeRow, eventTime: Long): UnsafeRow = {


There is a lot of duplication with the original func in these funcs. Most of them , the major difference is which encoder/decoder api is called. Can we make them use common code and then each can pass in how they want to handle encoder/decoder. This will help reduce duplication and code maintenance.

micheal-o · 2026-01-25T22:06:45Z

...core/src/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateEncoder.scala

  def encodePrefixKey(prefixKey: UnsafeRow): Array[Byte]
  def encodeKey(row: UnsafeRow): Array[Byte]
  def decodeKey(keyBytes: Array[Byte]): UnsafeRow
+  def supportEventTime: Boolean


Why not implement another class that extends the KeyStateEncoder and adds this 3 methods?

We could, but that's just like checking boolean vs pattern matching to check the type, and use whole different methods based on the result of if-statement. I can still do the thing to avoid existing encoder to force implementing new methods, if it's preferable.

IMHO they are naturally different ones, though I had to add them here because the abstraction of KeyStateEncoder is used widespread and I can't easily expand to receive another kind of it.

micheal-o · 2026-01-25T22:06:53Z

...core/src/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateEncoder.scala

+   * @throws UnsupportedOperationException if called on an encoder that doesn't support event time
+   *                                       as postfix.
+   */
+  def encodeKeyForEventTimeAsPostfix(row: UnsafeRow, eventTime: Long): Array[Byte]


This doesn't seem like it should be implemented at this layer. We can have another Encoder class that adds this prefix/postfix after calling the underlying encoder.

micheal-o · 2026-01-25T22:07:08Z

...core/src/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateEncoder.scala

+  override def supportEventTime: Boolean = true
+
+  override def encodeKeyWithEventTime(row: UnsafeRow, eventTime: Long): Array[Byte] = {
+    dataEncoder.encodeKeyForEventTimeAsPrefix(row, eventTime)


This class should just take in its own implementation of Data encoder that adds the prefix/postfix. So that we don't need to add this APIs at the DataEncoder level.

I think that should be the same with prefix/range scan, right? I thought we were collecting the actual impl to DataEncoder.

...core/src/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateEncoder.scala

anishshri-db · 2026-01-25T21:24:47Z

...main/scala/org/apache/spark/sql/execution/streaming/state/HDFSBackedStateStoreProvider.scala

      throw StateStoreErrors.unsupportedOperationException("mergeList", providerName)
    }
+
+    override def initiateEventTimeAwareStateOperations(


The phrasing of this just seems a bit odd/non-conformant in this layer. Could we rename/rephrase this ?

anishshri-db · 2026-01-25T21:25:01Z

...core/src/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateEncoder.scala

  def encodePrefixKey(prefixKey: UnsafeRow): Array[Byte]
  def encodeKey(row: UnsafeRow): Array[Byte]
  def decodeKey(keyBytes: Array[Byte]): UnsafeRow
+  def supportEventTime: Boolean


Same here with all these methods

anishshri-db · 2026-01-25T21:25:49Z

...core/src/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateEncoder.scala

+   * Encodes key and event time, ensuring prefix scan with key and also proper sort order with
+   * event time within the same key in RocksDB.
+   *
+   * This method handles the encoding as follows:


Why not just expose this in a more generic fashion ?

HeartSaVioR · 2026-01-25T23:32:11Z

I'll clarify the intention.

I argue event time should have been considered as a first class at the first time when designing state store. We didn't do this, hence the operation with event time is always not performant (full scan), though it is indeed the way operator produces output on append mode and evicts state. I'd rather say I'm trying to fix it.

Note that prefix scan from session window (the reason we introduced prefix scan) is bound to the case of "event time as first class", and the usages of range scan are mostly against event time.

The only exception from the above is TWS which we separate out the data and the timer and the data won't be coupled with event time since timer will do it. While someone may argue this is a better design since we separate out the concerns, but I believe this doesn't perform well compared to the proposal.

So for me the attempt of generalization to remove the concept of event time here and replace it with long type or something is against the direction of proposal. If we have a case where data should be ordered in integer type - should we do the same and expose an API and etcetc? I don't think that has sufficient motivation. The motivation of event time as first class is that it is one of the core concept of the streaming engine and we had been ignoring it in state store.

HeartSaVioR · 2026-02-01T04:22:59Z

Now this PR is on top of another PR: #54083

… copies of APIs

HeartSaVioR · 2026-02-11T07:09:03Z

...rc/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateStoreProvider.scala

Suggested change

HeartSaVioR · 2026-02-11T07:09:09Z

...rc/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateStoreProvider.scala

      rocksDB.merge(keyEncoder.encodeKey(key), valueEncoder.encodeValue(value), colFamilyName)
    }

+


Suggested change

HeartSaVioR · 2026-02-11T07:09:14Z

...rc/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateStoreProvider.scala

        colFamilyName)
    }

+


Suggested change

HeartSaVioR · 2026-02-11T07:10:44Z

...rc/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateStoreProvider.scala

  private val AVRO_ENCODER_LIFETIME_HOURS = 1L
  private val DEFAULT_SCHEMA_IDS = StateSchemaInfo(0, 0)

+  type KeyValueEncoder = (RocksDBKeyStateEncoder, RocksDBValueStateEncoder, Short)


Suggested change

type KeyValueEncoder = (RocksDBKeyStateEncoder, RocksDBValueStateEncoder, Short)

HeartSaVioR · 2026-02-11T07:10:51Z

...rc/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateStoreProvider.scala

  private val DEFAULT_SCHEMA_IDS = StateSchemaInfo(0, 0)

+  type KeyValueEncoder = (RocksDBKeyStateEncoder, RocksDBValueStateEncoder, Short)
+


Suggested change

...core/src/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateEncoder.scala

…projection, some tests are failing

anishshri-db · 2026-02-11T19:13:43Z

...core/src/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateEncoder.scala

        }
        StructType(remainingSchema)
+      case _ =>
+        throw unsupportedOperationForKeyStateEncoder("createAvroEnc")


Can we improve the passed arg/error message ?

def unsupportedOperationForKeyStateEncoder( operation: String ): UnsupportedOperationException = { new UnsupportedOperationException( s"Method $operation not supported for encoder spec type " + s"${keyStateEncoderSpec.getClass.getSimpleName}") }

I feel like this should be sufficient as long as this isn't user-facing error?

anishshri-db · 2026-02-11T19:13:59Z

...core/src/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateEncoder.scala

  }
 }

+object TimestampKeyStateEncoder {


Lets add some high level comments here ?

anishshri-db · 2026-02-11T19:14:58Z

...core/src/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateEncoder.scala

+
+  val SIGN_MASK_FOR_LONG: Long = 0x8000000000000000L
+
+  def finalKeySchema(keySchema: StructType): StructType = {


Does it need to be public ? if so, can we rename the function ?

Will rename.

anishshri-db · 2026-02-11T19:15:19Z

...core/src/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateEncoder.scala

+}
+
+/**
+ * FIXME: doc...


Yeah yet to get there. Will update.

anishshri-db · 2026-02-11T19:15:59Z

...core/src/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateEncoder.scala

+    rowWithTimestamp
+  }
+
+  // TODO: Revisit this to support delete range if needed.


could we add a SPARK JIRA for this then ?

anishshri-db · 2026-02-11T19:16:07Z

...core/src/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateEncoder.scala

+}
+
+/**
+ * FIXME: doc...


Yeah yet to get there. Will update.

anishshri-db · 2026-02-11T19:17:04Z

...core/src/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateEncoder.scala

+  }
+
+  private val keySchemaWithoutTimestampAttrs = DataTypeUtils.toAttributes(
+    StructType(keySchema.dropRight(1)))


The implementations of the functions in both the encoders seem similar. Any common code we can reuse across both ?

Will try to dedup. Maybe singleton can provide the projection instances.

anishshri-db · 2026-02-11T19:21:44Z

...rc/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateStoreProvider.scala

      new StateStoreIterator(iter, rocksDbIter.closeIfNeeded)
    }

+    override def prefixScanWithMultiValues(


Is this related to the encoder change ? where do we plan to use this ?

This will be used in next PR. I can move this to next one or a separate PR if you mind.

Moved this out.

…ed in other PR

…s well...

anishshri-db · 2026-02-12T19:48:39Z

...core/src/main/scala/org/apache/spark/sql/execution/streaming/state/RocksDBStateEncoder.scala

+ * timestamp ordering.
+ *
+ * The encoder expects the provided key schema to have [original key fields..., timestamp field].
+ * The key has to be conformed to this schema when putting/getting from the state store. The schema


nit: has to conform to this schema

still pending ?

anishshri-db · 2026-02-12T19:49:30Z

.../org/apache/spark/sql/execution/streaming/state/RocksDBTimestampEncoderOperationsSuite.scala

+import org.apache.spark.util.Utils
+
+@ExtendedSQLTest
+class RocksDBTimestampEncoderOperationsSuite extends SharedSparkSession


nit: can we add a comment to explain what the suite is doing ?

anishshri-db · 2026-02-12T19:49:50Z

.../org/apache/spark/sql/execution/streaming/state/RocksDBTimestampEncoderOperationsSuite.scala

+
+  private def newDir(): String = Utils.createTempDir().getCanonicalPath
+
+  // TODO: Address the new state format with Avro and enable the test with Avro encoding


Can we add a JIRA ticket for avro support ?

https://issues.apache.org/jira/browse/SPARK-55145 - I'll update here as well.

anishshri-db · 2026-02-12T19:50:18Z

.../org/apache/spark/sql/execution/streaming/state/RocksDBTimestampEncoderOperationsSuite.scala

+
+    test(
+      s"Event time as postfix: prefix scan operations (encoding = $encoding)"
+    ) {


nit: move to line above ?

Cursor does this all the time. Will change.

anishshri-db · 2026-02-12T19:51:54Z

.../org/apache/spark/sql/execution/streaming/state/RocksDBTimestampEncoderOperationsSuite.scala

+          // Prefix scan should find all entries with the same key across different event times
+
+          // Insert in non-sorted order to verify that prefix scan returns them sorted by time
+          store.put(keyAndTimestampToRow("key1", 1, 2000L), valueToRow(102))


Can we make sure we have enough coverage for different sort orders ? i.e. numbers with different binary lexicographic encodings to make sure results are as expected ? we could use values from other encoder tests ?

Done, fd6d1aa

anishshri-db

lgtm pending nits and green CI

HeartSaVioR · 2026-02-15T08:11:48Z

https://github.com/HeartSaVioR/spark/actions/runs/22030638407/job/63655143981
The CI only failed on docker integration module which is not related.

HeartSaVioR · 2026-02-15T08:12:08Z

Thanks! Merging to master.

… class (UnsafeRow) ### What changes were proposed in this pull request? This PR proposes to introduce key encodings which include "timestamp" as the first class. Proposed key encodings: * `TimestampAsPrefixKeyStateEncoder` / `TimestampAsPrefixKeyStateEncoderSpec` * Place event time as a prefix, and key as remaining part of serialized format * `TimestampAsPostfixKeyStateEncoder` / `TimestampAsPostfixKeyStateEncoderSpec` * Place key first, and event time as a postfix of serialized format The type of timestamp is LongType (long) - when serializing the timestamp, we flip the sign byte and store the value as "big endian". This ensures the natural ordering of long type, across positive, 0, and negative values. The serialization format of the original key is the same, e.g. for UnsafeRow, same as underlying binary format. These encodings are specification of prefix and range key encodings: * `TimestampAsPrefixKeyStateEncoderSpec` provides the range scan with timestamp. * `TimestampAsPostfixKeyStateEncoderSpec` provides the prefix scan with the key, additionally provides the range scan with the remaining timestamp. NOTE: The range scan with timestamp is only scoped to the same key. Compared to the prefix/range key encoding, this can eliminate the overhead of combining two UnsafeRows, minimum 12 bytes in each key in overall (8 bytes of null-tracking bitset, 4 bytes of storing length for one of two UnsafeRows). It can also skip projection(s) from deserialization as well. To cope with the existing StateStore API which does not have a concept of timestamp on API layer, we require the caller to project the key row to attach the timestamp manually before calling the StateStore API. Flipping the coin, the key row being produced by the StateStore API will be also the form of original row + timestamp and caller is responsible to project the original row from the returned row. Note: the performance is not optimal since there are multiple places of projections (array creation and memcpy), and we will need to introduce API level of change to eliminate these projections. The change is big already, so this PR only enables the new key encoding with UnsafeRow. Supporting Avro will be a follow up work. ### Why are the changes needed? The existing key encodings are too general to serve the same with noticeable overheads, in terms of additional bytes on serialized format. The proposed key encodings will do the same with minimized overhead, given the fact it only needs to handle timestamp along with the key. ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? New test suite. ### Was this patch authored or co-authored using generative AI tooling? Generated-by: claude-4.5-sonnet The above is used for creating a new test suite. All other parts aren't generated by LLM. Closes apache#53911 from HeartSaVioR/SPARK-55129. Authored-by: Jungtaek Lim <[email protected]> Signed-off-by: Jungtaek Lim <[email protected]>

…encoders ### What changes were proposed in this pull request? This PR proposes to support Avro for timestamp key encoders, TimestampAsPrefixKeyStateEncoder(Spec) and TimestampAsPostfixKeyStateEncoder(Spec). This PR does not cover the scope of enabling Avro for stream-stream join operators; this would trigger more scope than expected e.g. schema evolution and warrant separate effort. ### Why are the changes needed? To resolve TODO we left in #53911 ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? Existing UTs expanded from UnsafeRow only to UnsafeRow and Avro. ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude 4.6 opus Closes #54844 from HeartSaVioR/SPARK-55145. Authored-by: Jungtaek Lim <[email protected]> Signed-off-by: Jungtaek Lim <[email protected]>

…encoders ### What changes were proposed in this pull request? This PR proposes to support Avro for timestamp key encoders, TimestampAsPrefixKeyStateEncoder(Spec) and TimestampAsPostfixKeyStateEncoder(Spec). This PR does not cover the scope of enabling Avro for stream-stream join operators; this would trigger more scope than expected e.g. schema evolution and warrant separate effort. ### Why are the changes needed? To resolve TODO we left in apache#53911 ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? Existing UTs expanded from UnsafeRow only to UnsafeRow and Avro. ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude 4.6 opus Closes apache#54844 from HeartSaVioR/SPARK-55145. Authored-by: Jungtaek Lim <[email protected]> Signed-off-by: Jungtaek Lim <[email protected]>

github-actions bot added SQL STRUCTURED STREAMING labels Jan 22, 2026

HeartSaVioR force-pushed the SPARK-55129 branch from 2b144db to 62264ab Compare January 23, 2026 02:33

HeartSaVioR mentioned this pull request Jan 23, 2026

[SPARK-55144][SS] Introduce new state format version for performant stream-stream join #53930

Closed

micheal-o reviewed Jan 25, 2026

View reviewed changes

anishshri-db reviewed Jan 25, 2026

View reviewed changes

HeartSaVioR force-pushed the SPARK-55129 branch from 62264ab to db9ba48 Compare February 1, 2026 04:09

HeartSaVioR force-pushed the SPARK-55129 branch 3 times, most recently from f6058b9 to 64d18bb Compare February 2, 2026 12:20

HeartSaVioR changed the title ~~[SPARK-55129][SS] Introduce State Store API and key encoder for event-time as a first class (UnsafeRow)~~ [SPARK-55129][SS] Introduce State Store API and key encoder for timestamp as a first class (UnsafeRow) Feb 2, 2026

HeartSaVioR added 9 commits February 11, 2026 11:18

WIP code change, yet to add tests, yet to have method doc

1f0fa61

Introduce test for the change

a38f9dd

doc

d2ef0f6

fix

fe5c6ed

WIP Avro is broken

408ce83

Remove support of Avro at this point - we can handle it with follow-up

0367a66

doc

345410f

fix conflict

b4fb9ad

Renaming interface and encoder, deduplicate implementations among two…

bbe2145

… copies of APIs

HeartSaVioR force-pushed the SPARK-55129 branch 2 times, most recently from 0940a5f to cacd73d Compare February 11, 2026 06:49

HeartSaVioR changed the title ~~[SPARK-55129][SS] Introduce State Store API and key encoder for timestamp as a first class (UnsafeRow)~~ [SPARK-55129][SS] Introduce new key encoders for timestamp as a first class (UnsafeRow) Feb 11, 2026

HeartSaVioR commented Feb 11, 2026

View reviewed changes

Revert the API for (UnsafeRow, timestamp) and use the UnsafeRow with …

2e9ef79

…projection, some tests are failing

HeartSaVioR force-pushed the SPARK-55129 branch from 00f5341 to 2e9ef79 Compare February 11, 2026 07:14

HeartSaVioR requested a review from anishshri-db February 11, 2026 07:55

anishshri-db reviewed Feb 11, 2026

View reviewed changes

HeartSaVioR added 3 commits February 12, 2026 07:40

reflect review comments

eb073e9

revert the changes for addition of state store API - should be includ…

314acd4

…ed in other PR

additional doc

50da9ea

HeartSaVioR requested a review from anishshri-db February 11, 2026 23:03

HeartSaVioR mentioned this pull request Feb 11, 2026

[SPARK-55494][SS] Introduce iterator/prefixScan with multi-values in StateStore API #54278

Closed

HeartSaVioR added 2 commits February 12, 2026 08:46

fix tricky bug

b212a8b

Refactor a bit since these methods are actually needed from callers a…

c814c67

…s well...

anishshri-db reviewed Feb 12, 2026

View reviewed changes

HeartSaVioR added 2 commits February 13, 2026 22:10

new tests for diversed timestamps

fd6d1aa

review comments

29a060f

anishshri-db approved these changes Feb 13, 2026

View reviewed changes

HeartSaVioR added 3 commits February 14, 2026 08:10

missed

4660ce1

move out multiple values

e938ede

fix

bde927c

HeartSaVioR closed this in cc9913b Feb 15, 2026

HeartSaVioR mentioned this pull request Mar 17, 2026

[SPARK-55145][SS] Support Avro for timestamp based RocksDB state key encoders #54844

Closed

		rocksDB.merge(keyEncoder.encodeKey(key), valueEncoder.encodeValue(value), colFamilyName)
		}

		private val DEFAULT_SCHEMA_IDS = StateSchemaInfo(0, 0)

		type KeyValueEncoder = (RocksDBKeyStateEncoder, RocksDBValueStateEncoder, Short)


		val SIGN_MASK_FOR_LONG: Long = 0x8000000000000000L

		def finalKeySchema(keySchema: StructType): StructType = {


		private def newDir(): String = Utils.createTempDir().getCanonicalPath

		// TODO: Address the new state format with Avro and enable the test with Avro encoding

Conversation

HeartSaVioR commented Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changes were proposed in this pull request?

Why are the changes needed?

Does this PR introduce any user-facing change?

How was this patch tested?

Was this patch authored or co-authored using generative AI tooling?

Uh oh!

github-actions bot commented Jan 22, 2026

JIRA Issue Information

Uh oh!

HeartSaVioR commented Jan 23, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HeartSaVioR commented Jan 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HeartSaVioR commented Feb 1, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

HeartSaVioR commented Jan 22, 2026 •

edited

Loading

HeartSaVioR commented Jan 25, 2026 •

edited

Loading