fix: update queries refactor #390

pratikmishra356 · 2025-01-29T09:47:48Z

Problem

Redundant fetch and all columns update

Solution

Created new changeset request type for normal api request and added a function to map to changeset type

Environment variable changes

What ENVs need to be added or changed

Pre-deployment activity

Things needed to be done before deploying this change (if any)

Post-deployment activity

Things needed to be done after deploying this change (if any)

API changes

Endpoint	Method	Request body	Response Body
API	GET/POST, etc	request	response

Possible Issues in the future

Describe any possible issues that could occur because of this change

ayushjain17 · 2025-02-03T13:12:06Z

crates/context_aware_config/src/api/functions/types.rs

+impl UpdateFunctionRequest {
+    pub fn as_changeset(self) -> UpdateFunctionRequestChangeset {
+        UpdateFunctionRequestChangeset {
+            draft_code: self.function.map(|x| BASE64_STANDARD.encode(x)),
+            draft_runtime_version: self.runtime_version,
+            description: self.description,
+            change_reason: self.change_reason,
+        }
+    }
+}


Suggested change

impl UpdateFunctionRequest {

pub fn as_changeset(self) -> UpdateFunctionRequestChangeset {

UpdateFunctionRequestChangeset {

draft_code: self.function.map(|x| BASE64_STANDARD.encode(x)),

draft_runtime_version: self.runtime_version,

description: self.description,

change_reason: self.change_reason,

}

}

}

impl From<UpdateFunctionRequest> for UpdateFunctionRequestChangeset {

fn from(req: UpdateFunctionRequest) -> Self {

Self {

draft_code: req.function.map(|x| BASE64_STANDARD.encode(x)),

draft_runtime_version: req.runtime_version,

description: req.description,

change_reason: req.change_reason,

}

}

}

ayushjain17 · 2025-02-03T13:14:26Z

crates/context_aware_config/src/api/functions/handlers.rs

+            dsl::draft_edited_by.eq(user.get_email()),
+            dsl::draft_edited_at.eq(Utc::now().naive_utc()),


last_modified_at and last_modified_by not being updated here

@ayushjain17 it is not meant to be updated here,
for published code changes it gets updated

this is the update endpoint
and previously we were very much updating these two fields
ref

ayushjain17 · 2025-02-03T13:33:36Z

crates/context_aware_config/src/api/dimension/types.rs

+            function_name: match self.function_name {
+                Some(FunctionNameEnum::Name(val)) => Some(Some(val)),
+                Some(FunctionNameEnum::Remove) => Some(None),
+                _ => None,
+            },


lets extract this as a separate property of FunctionNameEnum
something like:

impl FunctionNameEnum { fn to_option(&self) -> Option<String> { match self { Self::Name(name) => Some(name), Self::Remove => None, } } }

ayushjain17 · 2025-02-03T13:35:19Z

crates/context_aware_config/src/api/dimension/types.rs

+impl UpdateReq {
+    pub fn as_changeset(self) -> UpdateReqChangeset {
+        UpdateReqChangeset {
+            position: self.position.map(|x| x.into()),
+            schema: self.schema,
+            function_name: match self.function_name {
+                Some(FunctionNameEnum::Name(val)) => Some(Some(val)),
+                Some(FunctionNameEnum::Remove) => Some(None),
+                _ => None,
+            },
+            description: self.description,
+            change_reason: self.change_reason,
+        }
+    }
+}


Suggested change

impl UpdateReq {

pub fn as_changeset(self) -> UpdateReqChangeset {

UpdateReqChangeset {

position: self.position.map(|x| x.into()),

schema: self.schema,

function_name: match self.function_name {

Some(FunctionNameEnum::Name(val)) => Some(Some(val)),

Some(FunctionNameEnum::Remove) => Some(None),

_ => None,

},

description: self.description,

change_reason: self.change_reason,

}

}

}

impl From<UpdateReq> for UpdateReqChangeset {

pub fn from(req: UpdateReq) -> Self {

Self {

position: req.position,

schema: req.schema,

function_name: req.function_name.map(FunctionNameEnum::to_option),

description: req.description,

change_reason: req.change_reason,

}

}

}

ayushjain17 · 2025-02-03T13:37:47Z

crates/context_aware_config/src/api/dimension/types.rs

+impl UpdateReq {
+    pub fn as_changeset(self) -> UpdateReqChangeset {
+        UpdateReqChangeset {
+            position: self.position.map(|x| x.into()),


is using into needed here ?
Position derives Deref, so it should be automatic na ?

yes its needed , deref does not removes the wrapper type

ayushjain17 · 2025-02-03T13:54:02Z

crates/context_aware_config/src/api/default_config/types.rs

@@ -13,7 +14,7 @@ pub struct CreateReq {
    pub change_reason: String,
 }

-#[derive(Debug, Deserialize)]
+#[derive(Debug, Deserialize, Clone)]


cloning entire req should not be needed

ayushjain17 · 2025-02-03T13:56:05Z

crates/context_aware_config/src/api/default_config/handlers.rs

+    let function_name = match req.function_name.clone() {
+        Some(FunctionNameEnum::Name(func_name)) => Some(func_name),
+        Some(FunctionNameEnum::Remove) => None,
+        None => existing.function_name.clone(),
+    };


why is this still needed ?
AsChangeset already handles this, right ?

this is being used for validation in another function , thats why need to extract it

in that case, can we use this:

Suggested change

let function_name = match req.function_name.clone() {

Some(FunctionNameEnum::Name(func_name)) => Some(func_name),

Some(FunctionNameEnum::Remove) => None,

None => existing.function_name.clone(),

};

let function_name = req.function_name.map_or_else(|| existing.function_name.clone(), |f| f.to_option());

ayushjain17 · 2025-02-03T13:57:19Z

crates/context_aware_config/src/api/context/operations.rs

@@ -75,6 +76,7 @@ pub fn put(
 pub fn r#move(
    old_ctx_id: String,
    req: Json<MoveReq>,
+    req_description: String,


req already contains the needed Description

it is of optional type ,
in move handler , at multiple places we needed non-option description
thats why we first check request or from db and then pass it to other utils function

can we not fix all of these and clean all these mess

Its not the scope of this PR,
anyway context apis are critical and a bit complex comparing to other apis , we can take it as an individual task to refactor implementation of context apis

ayushjain17 · 2025-02-04T07:49:02Z

crates/context_aware_config/src/api/config/handlers.rs

@@ -495,8 +498,19 @@ async fn reduce_config_key(
                    if is_approve {
                        let _ = context::delete(cid.clone(), user, conn, schema_name);
                        if let Ok(put_req) = construct_new_payload(request_payload) {
+                            let description = match put_req.description.clone() {
+                                Some(val) => val,
+                                None => ensure_description(


something seems wrong if we still need to use ensure_description even after all these changes

The pr was to remove redundant call not ensure description ,
this pr removes redundant update query and redundant ensure description call

All that I am saying is that ensure_description should not at all be needed after removing these redundant queries

its needed for config version table

@ayushjain17 ensure_description is being used in context handlers only
context apis are different like put and move request , where we need to have description either from the request
or from the db , ensure_description checks if contexts exist then fetch description from db
and if not then consider the request description and if missing in request then throw error

ayushjain17 · 2025-02-04T11:10:21Z

crates/context_aware_config/src/api/context/handlers.rs

@@ -67,21 +67,23 @@ async fn put_handler(
    schema_name: SchemaName,
 ) -> superposition::Result<HttpResponse> {
    let tags = parse_config_tags(custom_headers.config_tags)?;
+    let description = match req.description.clone() {
+        Some(val) => val,
+        None => ensure_description(


not reviewing the changes around ensure_description

this is still pending on my part

ayushjain17 · 2025-02-12T12:47:31Z

crates/superposition_types/src/database/schema.rs

@@ -13,7 +13,6 @@ diesel::table! {
        config_hash -> Text,
        tags -> Nullable<Array<Varchar>>,
        created_at -> Timestamp,
-        description -> Text,


shouldn't change_reason be removed and description be kept ?
because the change_reason of the action which created the snapshot becomes the description to the snapshot entry

ayushjain17 · 2025-02-12T12:52:27Z

crates/superposition_types/src/config.rs

@@ -1,8 +1,15 @@
 use std::collections::{HashMap, HashSet};

 use derive_more::{AsRef, Deref, DerefMut, Into};
+// use diesel::{deserialize::{self, FromSql}, pg::{Pg, PgValue}, serialize::{self, Output, ToSql}};


this can be removed

ayushjain17 · 2025-02-12T12:55:33Z

crates/superposition_types/src/config.rs

+#[cfg_attr(feature = "diesel_derives", derive(AsExpression, FromSqlRow))]
+#[cfg_attr(feature = "diesel_derives", diesel(sql_type = Integer))]
+#[serde(try_from = "i32")]
+pub struct Position(i32);


should this type (Position) and FunctionNameEnum be part of this file?
i feel like Position should be a part of models/cac.rs and for FunctionNameEnum it should be a part of the api subfolder in superposition_types

since Position is a part of Api as well as weight is derived from Position so it can be either in config.rs or in api/dimension.rs
FunctionNameEnum moved to function.rs file inside api

see, In Api we re-use stuff from other places which are more core in nature
models is the very core type on top which everything else is structured, so Apis do use types from other places and Position is not being used at that core level itself

Position cant be in models/cac.rs , I think models folder should refer to only table struct ,
other core types can be moved to other folders or files like api, config etc

One more thing we can do is keep them in both places. You can define them in models & then re-export it from api & then use the api import to have the same effect.

api and config are not core types, thats the misunderstanding we are having here
the very basis of both api and config types are models
not vice versa

ayushjain17 · 2025-02-12T12:59:06Z

crates/superposition_types/src/config.rs

+#[cfg(feature = "diesel_derives")]
+impl ToSql<Integer, Pg> for Position {
+    fn to_sql<'b>(&'b self, out: &mut Output<'b, '_, Pg>) -> SResult {
+        let value = self.to_owned().into();


why to_owned ?
any ways you need to pass reference to to_sql function

wont this be enough ?

Suggested change

let value = self.to_owned().into();

let value = self.into();

No this doesn't work as Into trait implies for Position and not referenced values

ayushjain17 · 2025-02-12T13:04:26Z

crates/context_aware_config/src/api/dimension/handlers.rs

+            let update_position =
+                Position::try_from(new_position).map_err(|err| unexpected_error!(err))?;


why is this still needed ?

ayushjain17 · 2025-02-12T13:25:53Z

crates/context_aware_config/src/api/default_config/handlers.rs

+    let function_name = match req.function_name.clone() {
+        Some(FunctionNameEnum::Name(func_name)) => Some(func_name),
+        Some(FunctionNameEnum::Remove) => None,
+        None => existing.function_name.clone(),
+    };


in that case, can we use this:

Suggested change

let function_name = match req.function_name.clone() {

Some(FunctionNameEnum::Name(func_name)) => Some(func_name),

Some(FunctionNameEnum::Remove) => None,

None => existing.function_name.clone(),

};

let function_name = req.function_name.map_or_else(|| existing.function_name.clone(), |f| f.to_option());

ayushjain17 · 2025-02-12T13:27:39Z

crates/context_aware_config/src/api/context/operations.rs

@@ -75,6 +76,7 @@ pub fn put(
 pub fn r#move(
    old_ctx_id: String,
    req: Json<MoveReq>,
+    req_description: String,


can we not fix all of these and clean all these mess

ayushjain17 · 2025-02-12T13:28:11Z

crates/context_aware_config/src/api/context/handlers.rs

@@ -67,21 +67,23 @@ async fn put_handler(
    schema_name: SchemaName,
 ) -> superposition::Result<HttpResponse> {
    let tags = parse_config_tags(custom_headers.config_tags)?;
+    let description = match req.description.clone() {
+        Some(val) => val,
+        None => ensure_description(


this is still pending on my part

crates/context_aware_config/src/api/config/handlers.rs

crates/context_aware_config/src/api/context/handlers.rs

ShreyBana · 2025-02-13T10:59:53Z

crates/context_aware_config/src/api/default_config/types.rs

+    pub schema: Option<Value>,
+    //function_name is nullable column, so to support null update with changeset
+    //we had to make it Option<Option<String>>
+    pub function_name: Option<Option<String>>,


Have you tested this?

Also why do we support removal of the function name? Isn't allowing people to change it good enough?

AND, why do we have FunctionNameEnum? Why not just Option<Option<String>> there as well?

Yes , it has been tested
that's subjective decision , if we let user to remove or only replace
Option<Option>> wont work on the request type since we cant derive option<option type after deserliaze

crates/context_aware_config/src/api/dimension/handlers.rs

crates/context_aware_config/src/api/dimension/types.rs

ShreyBana · 2025-02-14T13:52:56Z

crates/context_aware_config/src/api/functions/types.rs

+impl From<UpdateFunctionRequest> for UpdateFunctionRequestChangeset {
+    fn from(req: UpdateFunctionRequest) -> Self {
+        Self {
+            draft_code: req.function.map(|x| BASE64_STANDARD.encode(x)),


Why don't we create a new-type for this which automatically b64 decodes & encodes in to-and-from sql?
CC: @ayushjain17

That way you might be able to avoid creating this interface.

ShreyBana · 2025-02-14T13:57:18Z

.../superposition_types/migrations/2025-02-11-100518_remove_description_config_version/down.sql

I thought this PR was just for refactoring update queries 🤔 💭

ShreyBana · 2025-02-14T13:58:13Z

crates/superposition_types/src/api/function.rs

+use serde_json::Value;
+
+#[derive(Debug, Clone)]
+pub enum FunctionNameEnum {


I think we can just use Option<FunctionName>.

No we cant, as we have to support remove case

crates/superposition_types/src/config.rs

ShreyBana · 2025-02-14T14:09:56Z

crates/superposition_types/src/config.rs

+#[cfg_attr(feature = "diesel_derives", derive(AsExpression, FromSqlRow))]
+#[cfg_attr(feature = "diesel_derives", diesel(sql_type = Integer))]
+#[serde(try_from = "i32")]
+pub struct Position(i32);


One more thing we can do is keep them in both places. You can define them in models & then re-export it from api & then use the api import to have the same effect.

ayushjain17 · 2025-02-24T07:00:51Z

crates/superposition_types/src/database/models/cac.rs

+    D: Deserializer<'de>,
+{
+    let map: Option<Value> = Deserialize::deserialize(deserializer)?;
+    log::error!("function xxx {:?}", map.clone());


Return of Xander Cage ?

ayushjain17 · 2025-02-24T07:02:17Z

crates/superposition_types/src/lib.rs

@@ -16,6 +16,7 @@ use std::future::{ready, Ready};

 #[cfg(feature = "server")]
 use actix_web::{dev::Payload, FromRequest, HttpMessage, HttpRequest};
+use base64 as _;


why this ?
simply make bse64 option dependency and add it in the list of dependencies for diesel_derives

ayushjain17 · 2025-02-24T07:02:45Z

crates/superposition_types/src/database/schema.patch

what is the diff in this file ?
ideally there should not be any change in this file as there is no db level change being made in this PR

oh just checked, we are removing a column, but the patch file does not seem to be correct for that change, @pratikmishra356 can you please verify

I have verified we do not need any change in schema.patch
and this mandatory dimensions change is already there in main , the changes are same ideally it should not show something like this , will check after commit squash , not a breaking change

ayushjain17 · 2025-02-24T07:06:40Z

crates/superposition_types/src/database/models/cac.rs

+#[serde(try_from = "i32")]
+pub struct Position(i32);
+impl Position {
+    fn validate_data(position_val: i32) -> Result<Self, String> {


do we need this separately ?
should we move this directly inside try_from ?

ayushjain17 · 2025-02-24T07:08:15Z

crates/superposition_types/src/database/models/cac.rs

 use serde_json::Value;
+#[cfg(feature = "diesel_derives")]
+use std::str;


is this being used ?

also, can we follow this:

std package imports {{new_line}} package imports {{new_line}} crate imports {{new_line}} super imports {{new_line}} self imports

yes its being used

it is not right, std::str is a standard package, which should be moved at the top

Personally I feel that maintaining such things w/o CI checks is moot. You can't really rely on it being there through out the code base, just in files you were able to manage. Moreover it's there today & somebody may forget/screw it up tomorrow. To me it seems like fruitless work. How about we add the necessary checks via rustfmt instead?

ayushjain17 · 2025-02-24T07:08:46Z

crates/superposition_types/Cargo.toml

@@ -9,6 +9,7 @@ edition = "2021"
 # env
 actix-web = { workspace = true, optional = true }
 anyhow = { workspace = true, optional = true }
+base64 = { workspace = true }


Suggested change

base64 = { workspace = true }

base64 = { workspace = true, optional = true }

ayushjain17 · 2025-02-24T07:27:14Z

crates/context_aware_config/src/helpers.rs

@@ -294,7 +294,6 @@ pub fn add_config_version(
    state: &Data<AppState>,
    tags: Option<Vec<String>>,
    description: String,
-    change_reason: String,


this should be kept and the other removed, right ?

we are removing change_reason and keeping description
https://github.com/juspay/superposition/pull/390/files#r1952583143

ayushjain17 · 2025-02-24T07:29:55Z

crates/context_aware_config/src/api/functions/types.rs

 pub struct UpdateFunctionRequest {
-    pub function: Option<String>,
-    pub runtime_version: Option<String>,
+    #[serde(rename = "function")]
+    pub draft_code: Option<FunctionCode>,
+    #[serde(rename = "runtime_version")]
+    pub draft_runtime_version: Option<String>,
    pub description: Option<String>,
    pub change_reason: String,
 }


should we avoid such stuff?
since we dont have an api doc, these types are our only source for api spec and this sort of makes it complicated

As discussed, we're planning to do a breaking change to this API & the frontend already has the contract so not needed now.
CC: @pratikmishra356

ayushjain17 · 2025-02-24T07:31:26Z

crates/context_aware_config/src/api/dimension/types.rs

 pub struct UpdateReq {
    pub position: Option<Position>,
    pub schema: Option<Value>,
-    pub function_name: Option<FunctionNameEnum>,
+    #[serde(default, deserialize_with = "deserialize_function_name")]


default is not needed, right ?

Suggested change

#[serde(default, deserialize_with = "deserialize_function_name")]

#[serde(deserialize_with = "deserialize_function_name")]

ayushjain17 · 2025-02-24T07:34:54Z

crates/context_aware_config/src/api/dimension/types.rs

 pub struct UpdateReq {
    pub position: Option<Position>,
    pub schema: Option<Value>,
-    pub function_name: Option<FunctionNameEnum>,
+    #[serde(default, deserialize_with = "deserialize_function_name")]
+    pub function_name: Option<Option<String>>,


again, same point, changing here its like, when these types become common, which they are on the its way of becoming common

in the future sdk, the user would have to send data like: Some(None), Some(Some(function_name))
does not make sense in that way

over here, as long as we are seeing this type as something which is constructed only while deserialising, it can make sense, but in the longer run it just simply does not look correct

ayushjain17 · 2025-02-24T07:39:19Z

crates/context_aware_config/src/api/default_config/types.rs

-    pub schema: Option<Map<String, Value>>,
-    pub function_name: Option<FunctionNameEnum>,
+    pub schema: Option<Value>,
+    #[serde(deserialize_with = "deserialize_function_name")]


and then this requires us to keep writing this everywhere,
I would still say that there should be a separate type for this use case, as this is an action item which needs to be specify and not simply a param

making a separate type for this, clarifies the intent as well

Since were making a type, what's a good name for the field? I think something like:
function_association: Option<FunctionAssociation>

Will do this in next Pr ,
created the issue
#428

ayushjain17

Pending points being picked up later

pratikmishra356 requested a review from a team as a code owner January 29, 2025 09:47

pratikmishra356 force-pushed the update-query-refactor branch 4 times, most recently from f01a002 to 73a9e34 Compare January 30, 2025 08:17

ayushjain17 requested changes Feb 4, 2025

View reviewed changes

Datron linked an issue Feb 7, 2025 that may be closed by this pull request

Update requests performing un-necessary queries for optional fields #366

Closed

pratikmishra356 force-pushed the update-query-refactor branch 5 times, most recently from f8f0e65 to 3ec789f Compare February 11, 2025 07:06

pratikmishra356 requested a review from ayushjain17 February 11, 2025 07:24

pratikmishra356 force-pushed the update-query-refactor branch 3 times, most recently from d126437 to 8c9e659 Compare February 12, 2025 11:27

ayushjain17 requested changes Feb 12, 2025

View reviewed changes

pratikmishra356 force-pushed the update-query-refactor branch 2 times, most recently from 503d81a to 4d11865 Compare February 13, 2025 07:58

pratikmishra356 requested a review from ayushjain17 February 13, 2025 08:00

pratikmishra356 force-pushed the update-query-refactor branch from 4d11865 to 83f1fb0 Compare February 13, 2025 08:22

ShreyBana reviewed Feb 13, 2025

View reviewed changes

crates/context_aware_config/src/api/config/handlers.rs Outdated Show resolved Hide resolved

pratikmishra356 force-pushed the update-query-refactor branch 6 times, most recently from b172c42 to 7b50e2f Compare February 14, 2025 07:12

pratikmishra356 requested a review from ShreyBana February 14, 2025 07:53

ShreyBana requested changes Feb 14, 2025

View reviewed changes

pratikmishra356 force-pushed the update-query-refactor branch from 7b50e2f to 011ee28 Compare February 20, 2025 07:42

pratikmishra356 requested a review from ShreyBana February 20, 2025 07:45

pratikmishra356 force-pushed the update-query-refactor branch 8 times, most recently from e73ea65 to b0c5943 Compare February 21, 2025 10:14

ayushjain17 reviewed Feb 24, 2025

View reviewed changes

ayushjain17 requested changes Feb 24, 2025

View reviewed changes

pratikmishra356 force-pushed the update-query-refactor branch 3 times, most recently from e008f27 to cfca186 Compare February 24, 2025 13:52

ayushjain17 approved these changes Feb 24, 2025

View reviewed changes

ShreyBana approved these changes Feb 25, 2025

View reviewed changes

pratikmishra356 force-pushed the update-query-refactor branch from cfca186 to 2b5f479 Compare February 25, 2025 04:45

pratikmishra356 requested a review from ShreyBana February 25, 2025 06:28

Datron linked an issue Feb 25, 2025 that may be closed by this pull request

Redundant querying of description in updates #351

Closed

ShreyBana approved these changes Feb 25, 2025

View reviewed changes

Datron linked an issue Feb 25, 2025 that may be closed by this pull request

Refactor two separate update steps/queries #358

Closed

fix: optimize db query for update

24af34b

pratikmishra356 force-pushed the update-query-refactor branch from 2b5f479 to 24af34b Compare February 25, 2025 07:01

pratikmishra356 merged commit 258933f into main Feb 25, 2025
4 checks passed

pratikmishra356 deleted the update-query-refactor branch February 25, 2025 08:18

		dsl::draft_edited_by.eq(user.get_email()),
		dsl::draft_edited_at.eq(Utc::now().naive_utc()),

		let update_position =
		Position::try_from(new_position).map_err(\|err\| unexpected_error!(err))?;

	base64 = { workspace = true }
	base64 = { workspace = true, optional = true }

	#[serde(default, deserialize_with = "deserialize_function_name")]
	#[serde(deserialize_with = "deserialize_function_name")]

fix: update queries refactor #390

fix: update queries refactor #390

Conversation

pratikmishra356 commented Jan 29, 2025

Problem

Solution

Environment variable changes

Pre-deployment activity

Post-deployment activity

API changes

Possible Issues in the future

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pratikmishra356 Feb 13, 2025 • edited Loading

Choose a reason for hiding this comment

ayushjain17 Feb 13, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pratikmishra356 Feb 17, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ayushjain17 Feb 24, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pratikmishra356 Feb 24, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pratikmishra356 Feb 13, 2025 •

edited

Loading

ayushjain17 Feb 13, 2025 •

edited

Loading

pratikmishra356 Feb 17, 2025 •

edited

Loading

ayushjain17 Feb 24, 2025 •

edited

Loading

pratikmishra356 Feb 24, 2025 •

edited

Loading